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

re: units: the units should be added, ms is an option, but publication period is already in us.
re: rollover: good point. 64bit is an option, but that would mean we'd either have to do some trickery on the `simple_message` side (`shared_int` is defined as `int`), or add an additional type. Many controllers do not support 64bit integers either.
re: use case: I had indeed only the relative differences in mind when adding this and especially for analogue IO. Measuring analogue values (over time) seems meaningless to me without a timestamp. Ideally the controller is able to publish at the rate configured by the client, but might not be able to. An explicit timestamp might help in that case

I agree on the problem with resolution on some controllers, which is why I made *local timestamp support* a feature that is reportable. I'm not too enthusiastic about the field though, so I'd welcome some more opinions / input on it.