feat: New exposure method to specify variant and payload

[TizianoCoroneo]

Summary

This PR adds a new method to the Experiment protocol to perform an exposure specifying which variant was exposed to the user.

In our project we used all kinds of feature flag providers: initially we had our own solution on our server, then we used Firebase Remote Config, then Optimizely, now Amplitude. As a result, we have a robust internal framework developed to isolate ourselves from third party dependencies that might change... unexpectedly 🥲
To integrate with the Amplitude SDK we implemented the SDK as usual, turned off automatic exposure, and implemented a callback to pass exposure events from our framework to Amplitude's ExperimentClient.exposure(key: String) method.

Our framework has its own caching and override layers. Our usual workflow is the following:

• the app launches
• it reads the flags from cache to prepare the UI
• THEN downloads the latest flag variants, and stores them for next launch

This implies that once a feature flag value changes, the app will actually display the latest value with a delay of 1 app launch, because:

• ...app launch 0
• read old value from cache
• ⚡️ feature flag changes from old -> new
• ...app launch 1
• read old value from cache
• fetch and store new value
• ...app launch 2
• read new value

The issue is that during "app launch 1", Amplitude SDK has the latest flag values, while our layer is serving the old feature flag value from cache. When our callback calls ExperimentClient.exposure(key: String), the SDK loads the variant from its internal data, without knowledge of our cache layer, determines that the flag must be true and reports that to analytics, while the application is actually displaying the previous flag value.

This PR introduces a new exposure method to pass explicitly which variant and payload values were exposed to the user, so that our framework can pass accurate exposure information to Amplitude SDK.

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?: no