feat: ConfigCat web provider

[lukas-reining]

We should add a ConfigCat web provider. The discussion started in a PR of @adams85.

Thanks for the release, @lukas-reining. I did a quick test and found that the new version (v0.6.0) works fine.

Maybe we should also consider developing a client-sdk provider, as this is a server sdk provider. Which makes you change even more important.

Since our SSR SDK can handle both targets, I guess the client provider would be more or less just a duplicate of the server one (at least, in our case). I'd avoid maintaining another package if possible.

BTW, NPM packages kind of support multitargeting via the browser field. AFAIK, most of the bundlers support it nowadays. I have plans to look into the viability of this approach because it would be a godsend to us if we could merge our various JS SDK packages (or at least some) into one.

Originally posted by @adams85 in https://github.com/open-feature/js-sdk-contrib/issues/796#issuecomment-2010312985

@adams85 I am fully with you trying to not have a second provider codebase for the web that is just a copy of the server SDK, but in my opinion this is not the case for OpenFeature.

Problem

The provider interface of the @openfeature/web-sdk is different from the one in the @openfeature/server-sdk. Mainly the difference from the API side is that the web SDK evaluates synchronous while the server SDK evaluates async. This is due to the web SDK using the static context paradigm while the web SDK uses the dynamic context paradigm. The reasoning for this can be seen at Petes article in our blog https://openfeature.dev/blog/catering-to-the-client-side.

Solution

To reduce the amount of duplicate code we should move context-tranformer.ts and utilities like toResolutionDetails from config-cat-provider.ts to a shared folder. For the server there would be noting more left to do.

For the client I think we could use snapshots for the synchronous flag evaluation. The snapshot could be made in the initialize method of the provider as described in your docs and then be auto-polled. The rest of the logic should be same besides being sync then.