[k2] transport module

[neonphog]

This module is the k2 abstraction around tx5.

It should start by using the "memory" backend implementation for testing. We can set up the config to allow true networking at a later time.

I changed my mind. It'd be nice if the "core" k2 crate didn't have a dependency on tx5. We should re-implement a memory stub tx module for the first iteration, and later can create the production crate that brings in tx5.

AC:

• the tx module api allows:
  • sending a notify message to a remote
  • handling incoming notify messages
  • sending preflight messages
  • handling incoming preflight messages
  • sending module specific messages
  • registering a runtime handler for receiving module specific messages
• the stub tx module implementation allows all the above functionality within a local process only