Consider changing class Transform to have Configurable and Enable be virtual

[joelkoz]

In an attempt to make some of the other previous Transforms like Debounce use templates, an issue was discovered: by putting the implementation of everything in the .cpp file, the compiler will not be capable of generating a Debounce<> class for any future data types (e.g. Debounce<SomeFutureDataType>, as it will be blind to the implementation. On the other hand, if you put the entire implementation in the header file (esp. the configuration stuff) the compiler will generate a TON of redundant code.

The compromise is to make an interim base class and put the common code that is NOT type specific in and put that common code in the .cpp. Then we'd put the "type specific code" in the header file. This technique was used in SKPutRequest(). The problem with that code however is SKPutRequest() is a ValueConsumer and not a full blown Transform. It is not possible to introduce Transform into the inheritance hierarchy once Configurable has already been used (as was done for SKPutRequestBase) UNLESS we define class TransformBase's inheritance to be virtual Configurable and virtual Enable.

It is true that SKPutRequest() could have been defined as a ValueConsumer<> and also ValueProducer<> (which are the key components of Transform) and MOST of the functionality would be preserved. However, the "chained connect_to()" calls would not work, as those only work with Transform (at the moment). An alternative to changing TransformBase is to simply find a way to make "chained connect_to()" work with any class that is a ValueConsumer and ValueProducer, and not require Transform at all.

[ba58smith]

Note for @joelkoz, from a post on Slack: https://stackoverflow.com/questions/46226021/c-function-parameter-that-extends-multiple-classes