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