Fix to allow send_handler to return write_data status

[laboratory10]

This is a proposed fix that is related to the Queue Overflow problem in #48. This would revert the return value of send_handler in StreamDriver.cpp to be the actual value instead of always OP_OK no matter what happened with the write operation. To allow this, a connection status variable was added to track whether the connection is currently active. If the connection has not been active but a Serial connection is again detected, the StreamDriver configure function is used to reinitialize the serial connection and restart the telemetry flow.

Note that this proposed fix does not prevent the ComQueue from overflowing, it just makes it overflow more gracefully. By send_handler returning something other than OP_OK to ComQueue, that component will leave that message in the queue. I don't see a way to return a status that would tell ComQueue that the send was unsuccessful but that it is ok to remove the item from the queue anyway, which is what would prevent the queue from actually overflowing.

So, when I disconnect and reconnect while I have the fprime-gds running, I actually see the warning hi QueueOverflow EVR like I did before. However, unlike before, data is still flowing and the ComQueue component isn't locked up waiting for Serial to be reinitialized.

As is, StreamDriver still works fine, but if people would prefer that it be possible for a proper status to be passed back to ComQueue this is a good way to do it in my opinion.

[laboratory10]

I've just added another commit that adds a writeRead port to match the Drv.I2cWriteRead input port in the fprime I2c interface specification here (https://github.com/nasa/fprime/blob/devel/Drv/Interfaces/I2c.fpp). I realized this would be necessary while adding some sensors to my project from the subtopologies in the fprime-sensors library.

For an example topology of how this port is used look here (https://github.com/fprime-community/fprime-sensors/blob/devel/fprime-sensors/MpuImu/Subtopology/Subtopology.fpp)