nova: remove native_cap method from cpu_session

Remove native_cap method which caused the cpu_session implementation of the
gdb server to fail.

Issue #478
nova: fix thread in page fault and getting paused

If a thread caused a page fault and later on get be paused, then it left
the recall handler immediately due to the pause call instead of staying
in this handler.

Add some (complicated) state machine to detect and handle the case. Still not
waterproof, especially server threads may never get recalled if they never get
a IPC from the outside.

Fixes #478
nova: create sm for signalling via pager

The 'pause' call on base-nova assumes that a thread can solely block in its
associated semaphore. Main reason is that so core can unblock a thread in order
that the recall exception gets delivered and the register state can be
obtained.

Unfortunately the signal session implementation creates a semaphore, which is
unknown by the pager code. Instead create the semaphore via the pager of the
thread, so that the pager can unblock the signal thread when a pause is issued.

Issue #478
run: use gdb_monitor by autopilot

Issue #478
nova: don't wait for workers in cpu_session::pause

If a local thread is attempted to be 'pause'd via cpu_session, don't wait
until it gets into the recalled state. If the caller is lucky it is, if not
return only the stack pointer.

Avoids deadlocking of the gdb when attached to a process running a server.

Issue #478
usb: fix storage with IOMMU enabled

Fixes #747
base: make FIFO elements zero-pointer save

fix #904
hw: cancel waiting for IPC requests

ref #899
hw: kill signal receivers

ref #899
hw: fix bug in Kernel::yield_thread

ref #899
launchpad: remove '\n' from PERR message

ref #899
hw: enable multiple compilation units in kernel

ref #899
hw: enable verbose thread starts

ref #899
hw: fix bug in Kernel::Thread::resume

ref #899
hw: return error code on IPC replies

ref #899
base: fix bug in Object_pool::first_locked

fix #899
Build trace policies with -std=gnu++11 enabled
terminal_mux.run: Let CLI monitor preserve RAM

This change allows for the testing of cli_monitor's automatic resource
balancing by executing the following command:

  start ram_eater --ram-limit 1G --count 5

The command starts 5 instances of a RAM-eating process, which is,
however, able to yield resources when instructed. The RAM quota for the
processes gets automatically extended because of the overly large limit
of 1 GiB, which is far more than CLI monitor's RAM resources (100 MiB).
When the RAM usage hits the preservation limit, CLI monitor broadcasts
yield requests to each ram_eater instance, which allow the scenario to
remain alive.
hw: throw expressive exceptions in signal session

ref #912
hw: avoid generic exceptions in signal framework

ref #912