Capability quota accounting and trading

This patch mirrors the accounting and trading scheme that Genode employs
for physical memory to the accounting of capability allocations.

Capability quotas must now be explicitly assigned to subsystems by
specifying a 'caps=<amount>' attribute to init's start nodes.
Analogously to RAM quotas, cap quotas can be traded between clients and
servers as part of the session protocol. The capability budget of each
component is maintained by the component's corresponding PD session at
core.

At the current stage, the accounting is applied to RPC capabilities,
signal-context capabilities, and dataspace capabilities. Capabilities
that are dynamically allocated via core's CPU and TRACE service are not
yet covered. Also, the capabilities allocated by resource multiplexers
outside of core (like nitpicker) must be accounted by the respective
servers, which is not covered yet.

If a component runs out of capabilities, core's PD service prints a
warning to the log. To observe the consumption of capabilities per
component in detail, the PD service is equipped with a diagnostic
mode, which can be enabled via the 'diag' attribute in the target
node of init's routing rules. E.g., the following route enables the
diagnostic mode for the PD session of the "timer" component:

  <default-route>
    <service name="PD" unscoped_label="timer">
      <parent diag="yes"/>
    </service>
    ...
  </default-route>

For subsystems based on a sub-init instance, init can be configured
to report the capability-quota information of its subsystems by
adding the attribute 'child_caps="yes"' to init's '<report>'
config node. Init's own capability quota can be reported by adding
the attribute 'init_caps="yes"'.

Fixes #2398

repos/hello_tutorial/doc/hello_tutorial.txt

@@ -76,6 +76,8 @@ C++ class in 'include/hello_session/hello_session.h'
 !{
 !  static const char *service_name() { return "Hello"; }
 !
+!  enum { CAP_QUOTA = 2 };
+!
 !  virtual void say_hello() = 0;
 !  virtual int add(int a, int b) = 0;
 !
@@ -91,7 +93,12 @@ across component boundaries.
 Furthermore, we use the interface to specify the name of the service by
 providing the 'service_name' method. This method will later be used by both
 the server for announcing the service at its parent and the client for
-requesting the creation of a "Hello" session.
+requesting the creation of a "Hello" session. The 'CAP_QUOTA' definition
+specifies the amount of capabilities required to establish the session.
+The specified amount is transferred from the client to the server at session
+creation time. For the "Hello" session, two capabilities are required, namely
+a dataspace capability for the server-side memory occupied by the session
+object and the actual session capability that refers to the RPC interface.
 
 The 'GENODE_RPC' macro is used to declare an RPC function. Its first argument
 is a type name that is used to refer to the RPC function. The type name can
@@ -251,6 +258,7 @@ entry to init's 'config' file, which is located at 'build/bin/config'.
 !   <default-route>
 !     <any-service> <parent/> <any-child/> </any-service>
 !   </default-route>
+!   <default caps="50"/>
 !   <start name="hello_server">
 !     <resource name="RAM" quantum="1M"/>
 !     <provides><service name="Hello"/></provides>
@@ -345,7 +353,7 @@ of the session interface. For our case, the file
 !  :
 !    /* create session */
 !    Genode::Connection<Hello::Session>(env, session(env.parent(),
-!                                                    "ram_quota=4K")),
+!                                                    "ram_quota=4K, cap_quota=4")),
 !    /* initialize RPC interface */
 !    Session_client(cap()) { }
 !};
@@ -413,6 +421,7 @@ at the _run/hello.run_ and look as follows:
 !  <default-route>
 !    <any-service> <parent/> <any-child/> </any-service>
 !  </default-route>
+!  <default caps="50"/>
 !  <start name="hello_server">
 !    <resource name="RAM" quantum="1M"/>
 !    <provides> <service name="Hello"/> </provides>