Draft of the Generic IO protocol extension of the Simple Message protocol

As per title.

It is probably easier to read the document rendered, you may use [this](https://github.com/gavanderhoorn/rep-ros-i/blob/rep-xxxx_generic_io/rep-ixxxx.rst) url for that. I've also pushed a PDF rendered with [restview](https://mg.pov.lt/restview/): [link](https://github.com/gavanderhoorn/rep-ros-i/raw/pdf_attachment/rep-ixxxx.pdf).

Comments may be added in-line here (on the commit), or at the bottom of this PR.

Some points for discussion:

 1. should ``seq`` field of ros-i header be used instead of ``message_id``
 1. should copied ROS Packet header structure be shown in more detail in this document (seeing as the original source doesn't explicitly give more detail on used types fi)
 1. should message structures be defined using `shared_int` and `shared_real`, instead of current C typedefs
 1. should a `name` field be added to `IO_INFO` ranges
 1. repeat `timestamp` field in `IO_STREAM_PUB` for each published range, instead of one per msg
 1. should streaming support be required
 1. should explicit support for IO timed with motion be added (ie: synchronise IO write/read execution with `time_from_start` in trajectories), or should that be a responsibility of the client

I had three reasons for adding this:

 1. depending on the transport used, in-order delivery is not something that is always guaranteed. The sequence nr may help here, but there is no requirement anywhere (afaik) in simple message that says that the server should 'intelligently' use it (ie: always copy sequence nrs from client into replies).
 1. for simple synchronous read/write operations, returning replies in the order requests were received is possible, but if we add something like motion-synced IO (some controllers (fi Fanuc) support setting 'time before' and other motion options especially for IO. The server would start the motion and essentially be free to process other msgs), we could potentially create situations where an `IO_WRITE` is executed in between two synced-writes (fi).
 1. this wasn't so much for dealing with multiple messages on the server, as it was for the client. I wanted to avoid complex sequence nr / ordered queue management in clients that supported more than one callback queue / spinner, hence the unique ID.