Refactoring datastore options in trove/common/cfg.py

Trove project now supports multiple datastores. Trove's abstract commonality is extended by each datastore implementation. Trove should continue to handle databases as plugins/components and need not carry any prior knowledge(as configuration) of a DB adapted to work with it.

The current implementation of datastore options tie the datastore configurations hardcoded in cfg.py.

Alternatively DB implementation joining trove should provide its configurations with module entry points. cfg.py shall load the configurations by calling the module level settings.

Following are the necessary discussion points driving this blueprint.

SlickNik: "I'm not a fan of adding a fallback to the default configuration, either. However, I do see that it's currently difficult for an external datastore implementation to load config values for its use. I'd be open to discussing a bp that implements dynamic configuration loading that would make this easier."

amcrn: "unless someone writes a blueprint and a rough poc proving a polymorphic load would work, and wouldn't have detrimental side-effects"

amcrn: " SnowDust: so for now, no defaults. as a side project, you can look into what it means to make it pluggable."