#121625# - method <ExtensionManager::getExtensionsWithSameId(..)> - catch certain exceptions to avoid crashes

- method <ExtensionManager::getAllExtensions(..)> - do not add bundled extensions twice to the map; the map can not hold a fourth entry.

std::ifstream's EOF bit is not something to be worry about
when the preceding operation was reading to the EOF

Patch by: Tsutomu Uchino

Clang has had problems with braced string literals of unsigned chars
(http://llvm.org/viewvc/llvm-project?revision=154756&view=revision)
so we have to avoid them if we need to compile with such versions

"data_" is an actual data pointer but "data" is a member function
(since vigra-1.4). The method resizeCopy() seems to confuse data and data_
which the clang compiler was happy to point out. The OOo patch to vigra-1.4
already solved that problem but it was lost in the upgrade to vigra-1.6

Workaround the issue for now.

Sinc(x) is a simple function used in communications. boost
happens to use it for quaternion math. The implementation is
simple, however it looks fun to re-use the boost function
even if just to say we are using quaternion math somewhere ;).

The performance difference is not likely to be huge but JIC,
set up a specific Boost math policy to limit type promotion
with it's corresponding impact. 

Many spreadsheets and math packages set the value of POWER( 0, 0)
to 1 as that sometimes is required for some calculations. This
is also done by the standard C99 libc pow() function.

In mathematical terms the value is an indeterminate form and
in strict mathematical sense such value should at least be
considered with caution.

OpenFormula permits implementation defined values of 0, 1
or error in this case. We shall now return NaN.

Clean some headers while here.

User defined literals (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf)
are already available in gcc 4.7 and clang 3.1 and this results in problems in code
where literal strings are concatenated without any whitespace inbetween.

Use a better approach than revision 1387711

The syntax is different and somewhat ugly as it doesn't seem
possible to manipulate directly the real or imaginary parts
but it is possible to use operator overloading.

This is done for "fun" and to keep in line with evolving C++
standards. Numerical results should be unaffected.