Add protocol composibility

[zippy]

Protocols need at least three types of composibility:

• chaining: linking one to the next like http links to a document handler protocol
• wrapping: like MIME Type protocol is wrapped inside http
• abstracting: being able to partially specify a protocol, i.e. leaving holes for the processes/roles/symbols to be used in a more concretized usage of that protocol.
• insertion/replacing: when you use a different protocol in place of an abstract one which satisfies the same "holes" but adds more, for example, replace "requesting" with "authorized requesting"

Example to build:

• Requesting protocol, a base protocol where pretty much everything is abstract, the symbols, the roles and the processes.
• A "recognizing" protocol that's like a ping, but in which a receptor responds with what protocols/carriers it listens with/on. This gets built on-top of the "requesting" protocol.

[zippy]

as of f46500374e0f5 therequester/recognizer examples are almost operational. However, sill missing getting the resolution of REQUEST_HANDLER working because currently we aren't treating the send_response process as a code template that would get filled by the REQUEST_HANDLER on resolution. i.e. o_resolve doesn't know how to look into the code and do template substitution. Some approaches:

• figure out some true code templating process and make that explicit, such as marking the process as needing resolution when run-tree gets built at match time.
• figure out how to move this into the params, then REQUESTER prototol's send_response remains a viable process .
• custom build a run-tree, instead of using an ACTION which assumes a defined process.

[zippy]

Ok, next step here is to find a general form for templating that we can apply to all semantic trees. Currently _o_resolve uses two hard-coded search algorithms for look for GOAL and USAGES in EXPECT action slots and SEMTREX_SYMBOL_LITERALS, which works for those two cases, but this would generalize that. It will also probably generalize INTERPOLATE_FROM_MATCH

[zippy]

Now that we have a templating engined (6cafbfa831) we still have to make the SLOTS in code get filled at run-time for this to work.

[zippy]

almost done as of 629ee7be271e which:

• fixes recognize protocol to be a properly templated and unwound protocol
• adds semantic map into expectations so they can handle templated actions
• _o_resolve now returns the unbound semantics
• _o_unwrap now also builds up a semantic map

Still to do:

• need to add a _o_initiate routine (which will become an instruction at some point) that kicks off a role's interaction.

[zippy]

as of 9baeea6637c:

• _o_initiate in place to start an interaction of a protocol. Also re-worked the code so the carrier is the interaction symbol, not the protocol symbol. This is a work-around to not yet knowing what the carrier should be for protocols.
• adds WEAL as equivalent to role/goal/usage but for protocols. We don't use it yet...
• adds defining data in base_defs with parens based notation, and uses this for defining protocols instead of that weird intermediate form I used before in _o_make_protocol_def (which we should probably just remove).

[zippy]

still to-do:

• figure out how to handle the templating and binding of USAGE data. Currently the body of the recognize message is (ACTUAL_SYMBOL:are_you) instead of just (are_you), but it's not clear yet how to fix this.
• figure out why testProcessSignatureMatching spec is broken

[zippy]

364482ce3e fixes testProcessSignatureMatching spec failure

[zippy]

e1d3423d631 now handles binding of USAGE data by looking for ACTUAL_VALUEs in the semantic map when doing template filling