base: provide template for unmanaged singletons

An unmanaged singleton is a singleton object that isn't
constructed or destructed implicitly through the C++ runtime
enviroment. The new header provides a helper to create such objects
and is located in src/base/include.

ref #989
hw: replace unsynchronized by unmanaged singleton

ref #989
base: natural default align in unmanaged singleton

I have no idea where the previous default alignment = 2 in the unsynchronized
singleton came from but as at least the Arndale IC-driver in base-hw needs an
alignment of 4 = address width, unmanaged singleton now uses sizeof(addr_t)
as default alignment.

ref #989
hw: use core-PD class to prevent singleton clashes

ref #989
hw: communicate UTCB dataspace through start info

To remap its UTCB to its context area later, a main thread needs
to know the according dataspace capability. This is done through
the start-info it receives from its creator at startup.

ref #989
run: test for main thread_base object

ref #989
base: avoid compiler warning in Thread::stack_top

The statement _context->stack[-1] triggered the compiler warning
'array subscript is below array bounds'.

ref #989
hw: rename kill_* functions in bin_*

In the future bin_* means the direct destruction of a kernel object
without any blocking. kill_* in contrast is used for bringing a
kernel object such as signal contexts synchronized into a sleeping
state from where they can be destructed without the risk of getting
broken refs in userland.

ref #989
hw: fix bug in Kernel::Thread::_print_activity

ref #989
hw: sync signal contexts directly as user

Kernel::signal_context_kill can be used by any program to halt the processing
of a signal context synchronously to prevent broken refs when core destructs
the according kernel object. In turn, Kernel::bin_signal_context doesn't block
anymore and destructs a signal context no matter if there are unacknowledged
signals. This way, cores entrypoint doesn't depend on signal acks of a
untrustworthy client anymore.

ref #989
hw: do not block on destruction of signal receiver

As synchronization of signal contexts is now the users business instead of
cores and the signal framework ensures that every context of a receiver gets
synchronously destructed before the destruction of the receiver itself
synchronization and thus blocking at the destruction of a kernel
receiver-object isn't necessary anymore.

ref #989
hw: cancel unresolved faults before pager dissolve

If an RM client gets dissolved the RM server tries to first
dissolve and then destruct the according pager object. As pager objects
previously cancelled unresolved faults only in destructor the dissolve
operation blocked forever when an unresolved fault existed.
As every pager object should get dissolved before it gets destructed
(signal-context complains otherwise) no more unresolved-fault cancelling
is needed in the destructor.

ref #989
hw: format fix in activity table

ref #989
hw: mark caller when printing an activity-table

ref #989
codezero: adjust pager ID to new thread order

ref #989
ldso: Support for setting global object values

Make 'set_program_var' accessible outside of 'rtld.c'. Also, compile
dynamically linked programs with the '-fPIC' option. Doing not so,
yields to program-global symbols being put in the '.symtab' section
(which can be stripped) only. In order to get access to global
variables from the dynamic linker, the symbols need to reside within
the '.dynsym' section additionally. Hence the '-fPIC'.

ref #989
fix #1002
base: show size as %zu instead %zd

For big numbers otherwise negative sizes for memory chunks are displayed.

Issue #1011
base: catch errors during ram_ds allocation

Issue #1011
nova: throw exception if ram_ds setup fails

Fail hard if no large enough virtual memory area can be found where to map
the memory from the kernel to core.

Additionally clear dataspaces in junks if it can't be done in one large junk.

Fixes #1011
os: extentend File_system interface with sync RPC

Users of a File_system_session might want to force a file system
to flush or rather to synchronize its internal cache. A concret
default implementation is provided because not all file systems
maintain an internal cache and are not required to synchronize
caches.

Fixes #1007.