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 e28591ea220264b74bba12020ff575adb2d0ef6f on acolomb:frame-exception into f1128a73e43f565bacedd1ae99d077d7c9c831f3 on AdvancedClimateSystems:master.