Formalize and implement configurable light federation protocol

[kltm]

Implement the protocol that we defined for light federation in a way like we implement the new workbenches (see: #316 #283).

For a more in-depth discussion, please see this document: https://docs.google.com/document/d/16DNkAO9YHKZmQjdVxq2B_ULYQDu7jjc0aciVKdTwX8w/edit?usp=sharing#heading=h.z3lcqr39kncx

The idea would be to have a config file that describes the remote endpoint location, the data to be sent over the wire, and what local endpoint to return to. From the description, get the buttons, labels, etc. into the right locations in the UIs (as variables, a la workbenches).

[kltm]

As well, there is the degenerate (single open-ended ID/label) use case to think about as well, but this will probably be spun out into its own ticket once the federation protocol has been put in for current bulk/modeling use cases.

Let's say that I want to use an external application to explore and get an ID, using this "football" protocol. Since I am not operating at the "shared" model level, it would be hard to communicate this information back to the calling widget in the client.

I'd like to figure out a way to reuse the federation football to work when running the noctua js client to use external tools to get a single ID. I can use the football at the model level because I am taking actions against the "shared" model, but the remote client has no way of communicating with my anonymous JS client directly--it's not part of the shared information communication framework (yet).

My likely approach is to give the widget to change/update a uuid and lock the callback in a closure; then send out the football to the remote client, which would post to noctua api; from there the noctua api would inject the result into the command stream with the uuid, which could then be resolved by listening clients. This is a lot of work, but in a way, most architecturally sane, and leaves room for other uses in the future. (And semi-"secure", and framework agnostic?)
This would require that the noctua api start pushing into the comms stream, but that isn't too too bad--a lot of clients already do this for x/y updates, join/exit, and the like.

In discussion with @jnguyenx, maybe something could be done with an iframe (hadn't considered that), but neither of us could think of anything concrete that involved the football, which is the selling point for me right now.

[kltm]

A theoretical example of the above (#403 (comment)) would be to jump out to AmiGO or some other browser (e.g. ECO, @mchibucos) when trying to fill in an input box, but not having quite enough information to be happy with the autocomplete (i.e. want to browse a tree or annotations). It has been noted that one can do essentially the same thing with iframes and/or cutting and pasting, but I think it would be better to try and get apps working together beyond APIs and scrapings.

[vanaukenk]

@kltm - do you want to leave this one open?

[kltm]

Out of pride, I'd like to keep this open the the moment (https://github.com/geneontology/noctua/projects/5).
If we have removed federation (e.g. Textpresso) from future potential roadmaps, would be safe to close out.