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

Two issues:

 1. 32 bits is enough resolution for a timestamp.  If the units (which we should define in this REP) are ms, then this would be about 50 days worth.  It's not so much that time would rollover every 50 days, but that any rollover would have to be handled.  Using 64 bits pretty much means rollovers will not occur.
 1. I question the value/use case for including timestamps.  Without a form of synchronization between the controller and PC clocks, the absolute value is meaningless.  This means that only relative values between PUB messages is meaningful.  Also, I would point out that the true timestamp of IO on a robot controller is unknown and could be as bad as 10ms on some controllers.