base-hw: build vea9x4 libs only with vea9x4 spec

Fix #561
base-hw: fix clean- and alignment-bugs in env

Ref #420
base-hw: env bug that caused missing boot modules

Fixes #420
base: rename generic Board drivers Board_base

To enable a repo to name its specific board driver 'Board'.

Fix #569
base-hw: reorganize core-driver headers

Ref #570
base-hw: ease core build

Merge core only libs into the target make-files.

Use base-hw specific Board drivers that inherit
from generic Board_base.

Use Page_flags::access_t instead of additional
page_flags_t.

Fix #570
base-hw & imx53: enable nested init

Fix #575
os & base-hw: freescale EPIT timer driver

Fix #576
base-hw & imx31: use generic EPIT timer in core

Ref #577
base-hw & imx31: userland timer driver

Fix #577
base-hw & cortex_a9: use caches in pagetable walks

Fix #472
base: avoid shift warning in register array

Fix #422
base-hw: don't use 'long' unnecessarily

Fix #581
base-hw & arm: write-through cache on uncached RAM

Fix #473
base-hw: use Genode::memcpy in base/ipc.cc

Ref #583
base-hw: use Genode::memcpy in kernel.cc

Fix #583
base-hw: Platform_thread::cancel_blocking

Ref #589
base: add memory barrier before releasing lock

When releasing a lock we must take care that all state is written back to
memory and is not cached in registers. The volatile flag of the lock variable
only means to the compiler that this value must be written immediately.
Other values changed before may be kept by the compiler in registers, which we
don't want here.

Additionally the compiler is free to reorder the code in order to optimize.
That means the code we intend to be executed inside the critical section can
get be reordered and can be executed after we reset the lock variable in the
unlock implementation. The volatile statement of the lock variable doesn't
prevent reordering of instructions which are independent.

By adding a explicit memory barrier, we force the compiler to generate code
that writes back all the register content to memory/cache (and avoid a
bunch of hard to find bugs ...)
base: replace obj_by_* by lookup_and_lock

Add functionality to lookup an object and lock it. Additional the case is
handled that a object may be already in-destruction and the lookup will deny
returning the object.

The object_pool generalize the lookup and lock functionality of the rpc_server
and serve as base for following up patches to fix dangling pointer issues.
base: fix dangling session pointers in rm_session

If page faults are handled concurrently (as for base-nova) the traverse lookup
call in rm_session_component must be thread safe, which it isn't.
If the faulting area is backed by nested dataspaces which are managed by
various rm_sessions then a race happens under following circumstances
(triggered occasionally by the bomb test).

The traverse lookup may return a pointer to a rm_session of a nested dataspace.
If the rm_session is in parallel subject to destruction it happened that faults
got enqueued to the faulters list of the deleted rm_session and internally to
a list of the current rm_session of the Rm_client.

During destruction of the faulting Rm_client the associated rm_session will
be dissolved from the Rm_client, which leads to dereferencing the
dangling pointer of the already destructed rm_session.

On base-nova the memory of the rm_session object get unmapped eventually, so
that the de-referencing of the dangling pointer caused page faults in core.

The memory on other kernels inside core never get unmapped so that the
bug doesn't trigger visible faults.

The patch replace the keeping of a rm_session pointer by a keeping a
capability instead. The rm_session object must be looked up now explicitly in
the Object_pool implementation, which implements proper reference counting on
the rm_session object.