[MAT-475] bumping gcc location.

This updates the GCC location to point to the custom 4.9.1 build
on the osx builder. All platforms are now on GCC 4.9.1.
[MAT-475] add to string to ComplexArrayContainer.

This adds toString() to the ComplexArrayContainer class. Noticed
this was missing when debugging so have added it for use in
future.
[MAT-475] catch by ref not val.

A few erroneous catches were catching by value not by reference.
This fixes all known locations, grepping for catch AND NOT &
now yields nothing of significance.
[MAT-475] OSX gets dynamic libstdc++ linkage again!

Due to a raft of problems with GCC itself, symbol visibility,
unknown issues with exceptions propogating across the DSO
boundary equivalent and probably some more things that will
materialise in the future, OSX needs to go back to dynamic
linkage. This commit re-implements this behaviour.

Brief summary:
* It seems GCC's -static-libstdc++ doesn't quite work out of
the box on OSX. The flag has no impact and this appears to be
due to the GCC arg parser consuming the flag before the OSX
specific arg translation rules are applied to the flag. In an
attempt to get around this problem, the specfile can be dumped
and edited applied to effectively trick GCC into doing the
right thing. (bug will be reported upstream).
* Once static linkage of libstdc++ is working, it turns out that
there are a number of problems relating to the two layer
namespace mixed with symbol visibility issues. Most of these can
be worked around by forcing a flat namespace but a few issues
still persist. These issues manifest in the form of free() errors
and then stack corruption a single unit test. This is simply not
acceptable and so this route is entirely abandoned until the
problem is better understood and the issues quantified.
* The build therefore is altered so that the OSX build makes use
of the 2 layer namespace for libstdc++ linkage. This means we get
the desired behavior of the C++ ABI/symbols from the tool chain
being permanently associated with the OG-Maths code by virtue of
the linker 2 layer namespace mechanism. This also means that the
libstdc++.6.dylib needs to be bundled into the OSX libs in the
jar. A manual check of the bundled e.g. librdag_dbg.0.dylib shows
that it does indeed resolve symbols to the bundled
libstdc++.6.dylib opposed to the system version, dynamic linking
is working correctly!

Whilst it is undesirable to have the build system behaving
differently on different platforms. Until numerous issues with
upsteam projects are cleared up and we've fixed visibility
behaviours in the code, this is a viable work around.