RTU: Raise exception for unexpected slave or function code in response

[acolomb]

For RTU links, the specification (section 2.4.1) says the following:
"When a reply is received, the Master checks the reply before starting
the data processing. The checking may result in an error, for example
a reply from an unexpected slave, or an error in the received frame."

Technically, such frame errors include a mismatch in the response CRC
or slave address. The CRC is handled by uModbus, but the slave
address is not checked. If the function code does not match the
request, uModbus will also happily parse it and return data which is
valid, but unrelated to the application's request. The latter two
should be regarded as a failure in send_message() as well, which this
change does by throwing a specific exception.

The standard goes on to specify that the "Response time-out" should be
kept running if a response comes from the wrong slave. However, no
such mechanism exists in uModbus yet (relying on the serial port RX
timeout). This simple approach does not fix that inconsistency with
the spec, but still allows better error handling in the application.

[coveralls]

Coverage decreased (-0.09%) to 96.175% when pulling e28591e on acolomb:frame-exception into f1128a7 on AdvancedClimateSystems:master.