[FEATURE] Provide option to opt-out of OpenFeature API singleton

[lukas-reining]

Requirements

The OpenFeature specification requires (should) the OpenFeature API to be a singleton [1]
This design works good for most use cases and makes using OpenFeature very simple in most languages and frameworks.
In the past there have been multiple cases where application authors asked for an option to get an instance of the API that is not a singleton.

Recently we had @MattIPv4 mentioning an issue using the singleton here in Slack [2]

Just been bitten by OpenFeature being a global singleton -- we have a plugin-based architecture for our frontend, and we use OpenFeature in the core as well as in some plugins. Because it is a global singleton, and the core loads first, the version that the core is using is forced upon all the plugins even if they have a different version installed themselves. 
....
Not only was the core version winning out because it loaded first into the global singleton, but the library from core that was loading it is externalised in our plugin builds and baked into our docker image, so even overriding the core's dependency locally didn't work.

Also there was an issue mentioned in #1218, where an Angular App was decomposed into multiple Angular Apps. In this scenario, initialization and shutdown of the OpenFeature SDK could not be coupled to the lifecycle of the individual apps due to the shared SDK.

In todays community meeting Leo and Aaron from Datadog (Eppo) shared they also had cases they could not use the singleton.

We should clarify if all the cases mentioned here can be solved adequately with the current "singleton only" approach or if there should be a mechanism to get a non-singleton instances in cases where it does not work differently.

[lukas-reining]

@MattIPv4 did an example implementation of a package local singleton (not bound to the window) in #1303

[aarsilv]

At Eppo we had customers request the ability to break free of a Singleton with our SDKs not for micro frontend or plugin conflicts but for juggling multiple static contexts. For example, for some flags they can initialize immediately and want those values consistent throughout the session, but then others maybe need some more information that becomes available later and for those flags they want the latest and greatest evaluations. (Note we also have tags to specify which groups of flags to load so we're not doing duplicative work)

[MattIPv4]

for juggling multiple static contexts. For example, for some flags they can initialize immediately and want those values consistent throughout the session, but then others maybe need some more information that becomes available later and for those flags they want the latest and greatest evaluations.

I'm not sure why they need to break away from the singleton for this, domains should give separation of static contexts?