Review modularization/service architecture and config for DataModelSupplier

[ianfore]

See addition of DataModelSupplier implementations in https://github.com/ianfore/data-connect-trino

Raises some questions about how DataModelSuppliers are modularized. Having them as services is a good approach, but should the specific clients be in the main code base? Or should the clients be external? In the latter case a running implementation would likely be told via some config details where to find its DataModelSuppliers.

Also in the examples in https://github.com/ianfore/data-connect-trino one model supplier was not implemented as a web service. That client accessed schema files locally.

The other DataModelSupplier was a hybrid. XML data dictionaries were accessed over http/ftp so in that sense the client was a true client. However, it also took on the responsibility of transforming the XML to the json schema required for Data Connect.

The original implementation, and the additions above were all pragmatic choices adequate for current needs, but we should anticipate how this would scale as more Data Connect implementations are added. These considerations are likely also relevant to the Starter Kit implementation being developed by the GA4GH tech team.