add client plugin system using CBOR + unix domain socket

[david415]

Reading from the "katzenpost client control socket" yields an infinite stream of event structs.
In particular, we simply encode them with CBOR and a 2 byte length prefix.

[int][CBOR OBJECT][int][CBOR OBJECT]...

These client events are already defined in:
https://github.com/katzenpost/client/blob/master/events.go

They are used in the "event channel".

Meanwhile writing to the control socket allows the client to send messages on the mixnet. The encoding must be 2 byte length prefixed CBOR. The CBOR message type for sending would be something like this:

type SentMessage struct {
	ID [64]byte
	DestinationProvider string
	DestinationService string
	Payload []byte
	WithSURB bool
}

Should the plugin system must handle multiple concurrent connections? For each connection, it is intended that this plugin protocol let's the plugin send and receive concurrently. Should each plugin that's running receive all the events? How can we handle the receive/event side correctly? If a client runs multiple plugins then there needs to be a way to distinguish their receive payloads so that they can be routed to the correct recipient plugin on the client device. I suppose we could use our SURBs to help us identify replies. This client library currently does that and internally tracks this by mean of a Message ID.

However this only helps us identify replies to our queries sent. Whereas Katzenpost clients may receive messages from additional SURBs previously sent or because another network entity knows our Provider and recipient message queue identity. The latter being what is essentially the Loopix recipient addressing. We don't want those design elements from Loopix. We do however want to enable clients to send bundles of SURBs. For the first MVP we can ignore this multi-SURB use case. But even in that case, it's just a matter of matching the SURB ID on incoming messages.

In the above example, SentMessage has an ID field. ID is intended to be matched with the MessageID field of the "message reply event". Our client library's plugin system runtime needs to handle the routing of these reply events and route them based on Message ID. This routing is necessary to support multiple concurrent plugins. However it would be an acceptable minimum viable product to initially have the plugin system assume only one plugin will be used.