Refactor downcast of message types in higher level components

[TVolden]

As I mentioned in #93, we downcast to check. This creates direct dependencies from higher level entities to lower level entities.

Here is an example where we downcast to check if it's an instance of a 3rd part library, thereby creating a hard dependency to that 3rd part library. In this case an XML component, and since XML is being replaced by json in the OCPP standard, this dependency is unfortunate:

                if (payload instanceof Document) {
                    logger.trace("Receive a message: {}", SugarUtil.docToString((Document) payload));
                } else {
                    logger.trace("Receive a message: {}", message);
                }

I have written a short guide to Visitor pattern, that may be a good solution for this issue:
https://github.com/ChargeTimeEU/Java-OCA-OCPP/wiki/Example-of-visitor-pattern-(In-C%23,-oh-my)

Any ideas and/or better approaches?

Is anyone of for a challenge?

[robert-s-ubi]

@TVolden I would fix this by moving the logging to SOAPCommunicator and JSONCommunicator, where the type of object is known.

The incentive to actually do this would be to get rid of the SOAP dependencies for the (presumably vast majority of) library users who only care about OCPP-1.6J and have no use for the OCPP-1.6S support.

But that requires bigger changes, as the SOAP support is now integrated in the ocpp-v1_6 subproject. So the SOAP parts would have to be moved to a dedicated subproject along with their dependencies (and SugarUtil), and then the above mentioned changes made to allow using the library with OCPP 1.6J support only.

[robert-s-ubi]

PR #397 implements the solution proposed above.