Capability protocols. Components capability protocol

[gparmer]

Details on normal component, capabilities protocols summarized in #251. Given that these are "normal" components, we title and denote this as the "component capability protocol", meant to be differentiated from the manager capability protocol.

The requirements of this protocol are

1. the initial (boot) thread will begin execution in the component, work its way through cos_init, and when it is complete, we need to notify the booter so that it can scheduler additional component activations. This is done using a static schedule created by the linker.
2. It is unclear what we want that thread to do after this initialization. It already has a stack, so perhaps we want to let it go execute in main? Otherwise, we reclaim its resources, and move on.
3. Access to the sinv capabilities to invoke other components, linked to the symbols that correspond to the functions they represent.
4. Access to the asnd and rcv capabilities that can be used both explicitly for control flow management and event notification, and transparently as a replacement for synchronous invocations when we want communication to be between cores. This will likely require a new library that doesn't expose component creation, but enables the use of asnd and rcv end-points.

We can discuss the best options for handling the capability layout for these goals here.

A first draft will focus on 1. and 3. The capability layout could be:

enum {
    COMP_CAPTBL_SRET = 0,
    COMP_CAPTBL_SINV_POSTINIT = 1,
    COMP_CAPTBL_SINV_ARRSTART = 2
};

Simple: As always, capability 0 is for return. Capability 1 is called by the thread that completes cos_init. After that, we have the array of the synchronous invocations. The linker, and the booter have to collaborate to match up the function symbols that the component wants to invoke, with the proper synchronous invocation capabilities.