Refactor extension repository system to be more cognizant of dynamically loaded custom data sources

The custom data source discovery and processing pipeline works well when all data sources are loaded together near the beginning of the SDK's lifecycle. However, to support more dynamic loading of plugins (as done through the PluginsLoader introduced in #21), the pipeline needs slight refactoring.

For instance, FinalizeDataExtensions() does work going through all custom data sources and ensuring their dependencies are met. Since ideally there is only one extension repository, calling this multiple times as new plugins are dynamically loaded results in redundant work being done: custom data sources are "finalized" every time a plugin is loaded.

As @jmaxson-ms pointed out in #21, we should also be aware of dependencies getting resolved after a plugin is initially loaded. This may be something we don't care about, since ideally a custom data source is loaded in conjunction with all of its dependencies.

Start by tracing FinalizeDataExtensions() and the PluginsLoader introduced in #21, then follow how the extension repository discovers and processes custom data sources. Determine how repeated finalization and dependencies resolved after plugin loading should be handled; the work is done when dynamically loaded plugins do not cause redundant processing and the dependency behavior is defined.