feat: buildAndInit for isolated client instances

[typotter]

---

labels: mergeable

Eppo Internal
🎟️ Fixes: FF-3888
📜 Multiple Eppo Clients
Configuration Side-loading

Motivation and Context

The init and getInstance() methods work on a singleton instance of the EppoClient which makes for a generally smooth developer experience given that the Eppo SDK essentially handles dependency management for the dev. This does have its own drawbacks, but those are not particularly relevant here.

There are use cases, however, when a non-singleton instance of the EppoClient is required. One such use case is embedding the Eppo SDK into a library which itself can be included in other applications. If that 3p library shipped with Eppo is integrated into another application that has the Eppo SDK running, there would be undefined behaviour as the SDK cannot handle this use case.

The init method (and class constructors) for EppoClient and subclasses have evolved organically over time, adding new options as new features are added to the clients. The very large options type is beginning to become a little untenable and disorganized so we take the opportunity to clean that up a bit here.

There are other limitations and drawbacks to the current model of instantiating an EppoClient statically and then initializing it when the code calls init including the awkward coupling of needing to wait for init to resolve in order to get a reference to an initialized client. We have an opportunity to decouple initialization and waiting to make for a better DX (in addition to giving the dev full control over managing the EppoClient reference (intrinsically allows for easier mocking in tests and will be consistent with the host applications existing DI approach).

This change must be done without a major version bump and completely preserve the existing singleton API

Description

• Refactor the initialization options by grouping related options and extracting different types for each.
• Each option type is then combined back into a type using the existing IClientConfig name (this keeps the change backwards compatible while offering a big win in option clarity)
  - New method: buildAndInit which creates an isolated client instance.
  - new method: waitForConfiguration which resolves when the first config is loaded.
• Docs

How has this been documented?

• https://linear.app/eppo/issue/FF-3926/[docs]-update-js-client-docs-to-describe-the-non-singleton-client

How has this been tested?

• tests

[typotter]

Several false starts and iterations later, we're ready for another review. Note: this PR is now stacked on #170 where changes are made just to how the singleton is referenced, leaving the focus of this PR on waitForConfiguration and buildAndInit.

[felipecsl]

Main feedback is around documentation and providing alternative APIs for what's been deprecated. I'm ready to approve after that, great work!

[typotter]

Thank you, @rasendubi @felipecsl @aarsilv for you reviews and patience as we explore this change.

I have made a key change - the singleton init and getInstance are no longer deprecated. I still fell that's the right direction to take, but for now, let's ship this feature and continue to polish afterwards.

PTAL