Need a better story around pluggable database implementations

[scgray]

WIth https://github.com/FoundationDB/fdb-record-layer/pull/1344, @panghy provided a mechanism by which the FDBDatabaseFactory can have alternative implementations. This resulted in some internal build errors in record layer that were addressed in https://github.com/FoundationDB/fdb-record-layer/pull/1384, however the way they were addressed doesn't really fix the underlying issue that the factory has a lot of methods that may or may not apply to alternative implementation.

This doesn't need to be addressed now, but if we really want to formalize this idea to have different implementation, it seems to me that it would make sense that:

• It is really the FDBDatabase that needed multiple implementations, not the factory...
• There probably should only be one implementation of FDBDatabaseFactory who's job is to produce databases, but...
• The implementations of databases returned could vary
• It would make sense to change the getDatabase(@Nullable String clusterFile) method to be more like getDatabase(@Nullable String url) where the URL can inform the type of database the factory produces. For example, the lack of a URI prefix or file:// could indicate a cluster file (like today), but grpc:// (or something like that) could indicate a proxy implementation

With this, the main thing that would need to be considered is a reasonable way by which the different implementations can be configured within the factory without adding like a million methods to the class.