Trait feature: introspection/trait/get_zomes_by_trait

[lucksus]

PR summary

Adds the ability to get instances/zomes by given trait.

New conductor admin function introspection/traits/get_zomes_by_trait receives one parameter trait which is expected to be a JSON object that describes a zome trait. Example:

{
    "name": "crypto",
    "functions": [
        {
            "name": "encrypt",
            "inputs": [{ "name": "payload", "type": "String" }],
            "outputs": [{ "name": "result", "type": "ZomeApiResult<String>" }],
        },
        {
            "name": "decrypt",
            "inputs": [{ "name": "payload", "type": "String" }],
            "outputs": [{ "name": "result", "type": "ZomeApiResult<String>"" }],
        }
    ]
}

The conductor then iterates over all running instances, retrieves their DNA, iterates over all zomes and for each zome checks if it implements the given trait, both by using the same name and all function signatures (i.e. function names, parameter names, ordering and types).

It then returns a list of all found zomes with their according instance id, so the caller has all information to call the found trait implementations next.

Example of returned format:

{ 
    "zomes": [ 
      { "instance_id": "app", "zome_name": "simple" } 
   ] 
}

app-spec-proc-macro

This branch also fixes the deactivated app-spec for hdk-proc-macro (HDK v2) which got deactivated in CI and became broken. I wanted to make sure this also works in HDK v2, which AFAIK is encouraged by the docs. Maybe app-spec should be switched over to proc-macro only?

followups

This mounts the new functions in all admin interfaces and no other interfaces. This is fine for first prototype implementations as needed by Junto, where the Junto installation maintains the conductor installation (in its own app bundle). In order to properly use traits in the context of Holoscape or Holo, we would need to make this available to non-admin interfaces as well. But that implies more complexity needed:

1. a way to control which hApps are allowed to find out about other DNAs.
2. If a hApp has found DNAs it wants to talk to, it should request to get access to those DNAs within the interface it is using already (-> a new function like introspect/instances/request_access which takes an instance ID and asks the user via pop-up if the requesting hApp should be granted access to an already running and different DNA).

changelog

• if this is a code change that effects some consumer (e.g. zome developers) of holochain core, then it has been added to our between-release changelog with the format

- summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)

documentation

• this code has been documented according to our docs checklist

[Connoropolous]

@lucksus I am guessing that trait matching as done here is shallow, in the sense that ZomeApiResult<String> only says so much, and that ZomeApiResult<SomeStruct> is also shallow, because SomeStructs full definition isn't provided to be matched against.
How are you thinking about that kind of thing?