SDK Function Call API + main class for SDK

[drinkcoffee]

This pull request creates a new entry point class for the SDK: net.consensys.gpact.CrosschainProtocols The idea is that this is the central point class from which all functionality can be accessed. The class allows for registration of new implementations from third party vendors. At present, this class only supports the function call API. Messaging layer classes will be added in a separate PR.

This pull request also creates an API for the function call layer. The example code access functionality using CrosschainProtocols and this API only: no access to implementation classes is needed. As a result of the common API, how to execute a crosschain transaction with the GPACT and SFC protocols has changed slightly. These changes are reflected in the example code.

[drinkcoffee]

When considering this PR, an important class to consider is: CrosschainProtocols. Is the API the approach that everyone is happy with: https://github.com/ConsenSys/gpact/pull/91/files#diff-50addbac16a7bfb7c1b8d7e0fb74f45176a6c25ce8cc7573639581643f4a72ac

[drinkcoffee]

Another thing which I have considered is moving all implementation / non API packages into a sub-package "internal". That is the packages from change as shown below. The idea would be to make it obvious that the classes should not be used directly, even if a constructor, method or field was public.

In this PR / current If we had "internal"
net.consensys.gpact.functioncall.common net.consensys.gpact.functioncall.internal.common
net.consensys.gpact.functioncall.gpact net.consensys.gpact.functioncall.internal.gpact
net.consensys.gpact.functioncall.sfc net.consensys.gpact.functioncall.internal.
sfc