Build: always link explicitly agrainst lib rt

This improves sane library dependencies, as mandated
by debian policy. Some of the librt functions are in such
wide use, that we'd get them through transitive dependencies
anyway. But linking explicitly against a function adds the
DT_NEEDED for this library to our build artefacts. This is
correct, since we're actually using these functions ourselves,
making them into direct dependencies.
bugfix: format-string for long and ulong values

our front-end for boost::format, the class lib::_Fmt
was lacking an reliable  specialisation for long and ulong.

This is due to the notorious problem of these types being
of platform dependant size. As a fix, we're speclialising
explicitly for int16_t, int32_t and int64_t and avoid the
common names 'short', 'int' and 'long' alltogether.

And especially for non-64bit-platform (NONPORTABLE)
we add an explicit specialisation for long
partial fix: use 64 framecounts (Ticket #882)

This is a partial and preliminary fix; we had an occasional
numeric overflow on 32bit platforms in some tests.

The complete fix will be to introduce a typedef and then
rework the relevant APIs (which are preliminary anyway,
thus no urge right now)
bugfix: occasional wrap-around on 32bit FSecs value in test code

this is rather a workaround.
The problem is a wraparound while calculating the common denominator in

Time rawTime (dirt + frames*F25);

Currently we're using boost_rational<long>, and long is only 32bit
on 32bit platforms. The workaround commited here just avoids
the calculation of the fractional value, and adds 64bit time values
instead. But the real solution would be to use a consistent
approach for dealing with frame counts and frame rates, all
based on 64bit values. See Ticket #939
continue development where we left before the release effort
introduce typedef for Frame numbers (see #882)
settle and implement some long standing concerns regarding #920

- what the dispatch operation actally is
- where the deadlines are established
TiddlyWiki: fix some orphaned pages

...caused by image names starting with upper case letter
explain the term 'subsystem'
fix error in test fixture

random offset should always be != zero
Ticket #925: remove LUID from interface/plugin specifications

In the November developer meeting, Christian and I agreed that
it's best to remove that offending LUID specifications altogether.

Those embedded LUIDs where one of the issues blocking the transition to C++11
Switch compilation to C++11 standard with GNU extensions

Why GNU extensions? They where on by default previously,
so we're changing nothing besides the C++ standard level.

AFAIK, we're using a GNU extension at one place, and this
could be replaced by 'decltype' now.
Switch from TR1 preveiw to the new standard headers

- functional
- memory
- unordered collections
unsuccessful attempt to bridge between std::hash and boost::hash_value  (Ticket #722)
minor improvement to the GUI-model Sequence

including a LUID based hash identity
C++11 transition fixes

- comparison of weak-pointers
Ticket #940: solution for binding GUI signals

 * use a development snapshot of lib SigC including the recent C++11 adaptations
 * never include whole namespaces. Here we got a clash between std::bind and sigc::bind
 * use lambdas
   * to make the binding code more readable
   * to take the nested invocations apart, which resolves the return type ambiguity
Ticket #942: introduce move semantics for our custom shared-ptr-wrapper lib::P
C++11 transition: get compilation to pass again

...but we have still 12 test failures
Scons: check for C++11 specific headers. Be more explicit w/r boost

we still don't check for the precise boost version number in the
SCons configuration. We might do so in future, but for now our
policy is that precise version dependency checking is the business
of the packager (i.e. the debian package). The SCons build just
has to ensure the absolute necessary baseline