Refactor RuntimeConfigProvider to be more extensible for Hot Reloading

[aaronburtle]

The current design utilizes a single RuntimeConfiProvider class to provide access to the RuntimeConfig, which this class currently stores internally. This refactor will break the RuntimeConfigProvider into separate classes for local and hosted scenarios, which both implement a common interface. Instead of storing the RuntimeConfig within the providers, we will store them in the RuntimeConfigLoader classes. For the hosted scenario, we are not immediately implementing hot reloading and so the HostedRuntimeConfigProvider may still store a RuntimeConfig internally until we have a separate HostedConfigLoader to handle the hosted scenario.

This also requires refactoring to correctly utilize each kind of provider, and also to properly register these various classes during initialization.

[seantleonard]

Moving this + hot reload related tasks to post GA -> tracking via 1.2rc milestone.

The current PR can be moved to draft or closed for the time being until we revisit this feature post-GA.

[seantleonard]

Moving some hot reload tasks to backlog so we can focus on tasks that add hotreload support various services/classes (openapi, authentication config). Once the pre-reqs are done, it will be easier to start updating the runtime config classes directly.