[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,
edited and 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 an invalid
free() and then stack corruption in 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, therefore dynamic
linking appears to be 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.