API Refactoring: add execute operation to requests, extract SPI package

[ghost]

API Refactoring proposal containing the following changes. The most important changes are:

Provide an execute() operation on PlcRequest, returning PlcResponse. This has already been discussed in the mailing list. The idea is to remove temporal coupling which forces the client to invoke operation in pairs: for example, creating the request off a PlcReader and submitting the created request back to the same PlcReader for execution.

Move PlcDriver away from the API into the SPI package. Since execution of the requests will be implemented on the request itself, one level of indirection (PlcReader, PlcWriter, PlcSubscriber, PlcProprietarySender) in the chain PlcConnection -> PlcReader -> PlcReadRequest.Builder -> PlcReadRequest becomes trivial and unnecessary. However, the execution of the requests will be performed differently depending on the protocol being implemented. This variation should be encapsulated behind the PlcReader interface, but it should not be exposed to the client. Therefore, these interfaces are placed in the driver-base module for protocol implementers.

Other minor changes include:

Remove default methods from the API. These were "workarounds" for sub-optimal API design. A public API should be as slim as possible, and default operations should be omitted.

PlcMessageBuilder renamed to PlcRequstBuilder. It is useful (and was acually used) only for constructing requests anyway.

Reduced the amount of generics. Many types were generic, which increased the complexity dramatically, but provided almost no benefit for the client. Wherever possible, the type parameters were removed to simplify the API.

[JulianFeinauer]

As stated on the list, I like it!