Bug fix: null ptr dereference in base/semaphore

If nobody is blocked in a semaphore, nothing can be dequeued. If
the semaphore is used for signalling, there can be somebody in the queue,
but not necessarily.
Bug fix: null ptr dereference in base/lock

Don't fail if nobody is holding the lock.
Fix: Avoid deadlock during cleanup of entrypoint

Invoke cancel_blocking before calling the
cleanup portal of the rpc_entrypoint. If a rpc_entrypoint
is blocked in a semaphore the cleanup call gets
stuck forever.
Don't deallocate invalid cap

SC slot is unused here.
Pager/Thread_start cleanups

Don't allocate ec cap twice, in pager.cc and thread_start.cc.
Unmap of utcb has to be done in destructor of thread class, not
in pager class. Free capability selectors of ec and rs.
Sanity resetting of Utcb words/items field.

Don't send words or mappings by accident. Reset the word/item
counter.
Move semaphore op codes to generic syscall
Use down-to-zero semaphore feature to block thread

Use semaphore down feature of NOVA to set the counter to zero.
If the semaphore was up()ed more than one time by impatient callers
(e.g. guys calling cancel_blocking) we make sure that the thread
really stops.
Fix: thread identifier comparator

The invalid thread is specified as 0,0,-1 (ec cap, sc cap, sem cap).
The main thread is specified as 0,0,0.

The comparator identified "tid_main == tid_invalid" as equal,
which is obviously wrong.

The patch compares at least ec and sem cap.
Fix: _session_list in child.h must be locked

The _session_list can be modified concurrently,
so the iteration over the list must be locked.
Cleanup: cap allocation

Allocate exc_pt_sel inside Thread_base object
instead of pager object, since it is a thread
specific characteristic.

Same for freeing of the thread capabilities:
- ec, sc, rs, exc_pt_sel is thread specific
and has nothing to do in server nor pager object.
NOVA: Deadlock fix in pager/rm_session interaction

Following deadlock happens when a Rm_client/Pager_object handles a page-fault
and concurrently the same object is dissolved (triggered by parent killing
the client).

The situation is as follows:

Page fault handling  :
base-nova/src/base/pager/pager.cc    : pf_handler() - lock pf_lock
base/.../core/rm_session_component.cc: pager()      - lock rm_session
  (in reverse_lookup())

Dissolve of Rm_client:
base/src/core/rm_session_component.cc: dissolve()   - lock rm_session
base-nova/src/base/pager/pager.cc    : dissolve()   - lock pf_lock

The pf_lock is not required here during normal page fault handling,
since this pager object @NOVA is executed only by one and the same
thread and all critical operations inside the rm_session_object itself
are locked anyway. The only critical point is the destruction of the
Pager_object which is already handled in the both dissolve functions
of the rm-session_component (locking) and the pager_object (finalize
in-flight page faults).
Feature: add synchronized allocator
Deadlock fix in rm_session on NOVA platform

Rm_client is derived from Pager_object. If the Pager_object is also
derived from Thread_base (which is the case for NOVA) then the
Rm_client object must be destructed without holding the rm_session_object
lock. The native platform specific Thread_base implementation has to take
care that all in-flight page handling requests are finished before
destruction. On NOVA it is done by doing an IPC to the pager thread.
(performed in Pager_object::dissolve() in base-nova). The
called thread than executes its operation until end which also requires
in some cases to take the rm_session_object lock.

Since _client_slab insertion/deletion also must be performed
synchronized but can't be protected by the rm_session_object lock
because of the described dead_lock situation, we have
to use a synchronized allocator object to perform insertion and
deletion of Rm_clients.
NOVA: update NOVA@github revision

Use latest NOVA github revision. Fixes sporadic in-kernel page faults.
NOVA: replace kernel patch

The current patch enable Genode to revoke unused UTCBs
of dead threads and so make Genode able to reuse the
same virtual address region for new threads later on.
This is actually the root reason why the vanilla kernel
doesn't work with Genode.