Fixes SDKONCALL-129.

Goal

The main feature that this change introduces is providing a request cache to ProductsFetcherSK2 (like ProductsFetcherSK1 has).
It already implements a product cache, but concurrent requests for the same products result in fetching those multiple times. It does not cache products until they're done being fetched.

This was observed in the logs when doing something simple like purchasing a product. This is running testCanPurchaseProduct integration test:

DEBUG: ℹ️ No existing products cached, starting store products request for: ["com.revenuecat.monthly_4.99.1_week_intro", "com.revenuecat.annual_39.99.2_week_intro", "com.revenuecat.weekly_1.99.3_day_intro"]
DEBUG: ℹ️ No existing products cached, starting store products request for: ["com.revenuecat.monthly_4.99.1_week_intro", "com.revenuecat.annual_39.99.2_week_intro", "com.revenuecat.weekly_1.99.3_day_intro"]
DEBUG: 😻 Store products request request received response
DEBUG: ℹ️ Store products request finished
DEBUG: 😻 Store products request request received response
DEBUG: ℹ️ Store products request finished

With this PR, we avoid the double request due to that race condition:

DEBUG: ℹ️ No existing products cached, starting store products request for: ["com.revenuecat.annual_39.99.2_week_intro", "com.revenuecat.weekly_1.99.3_day_intro", "com.revenuecat.monthly_4.99.1_week_intro"]
DEBUG: 😻 Store products request request received response
DEBUG: ℹ️ Store products request finished

How

Instead of implementing that logic only on ProductsFetcherSK2 or in ProductsManager, this aims to keep the implementation simple in ProductsManager and each of the fetchers, and instead uses the decorator pattern to provide that new functionality in a way that's simple to test and maintain, independent of the logic for actually fetching products.

To accomplish that, this adds a new protocol: ProductsManagerType, with 2 main methods (more about why the need for an SK2 special method below):

/// Fetches the ``StoreProduct``s with the given identifiers
/// The returned products will be SK1 or SK2 backed depending on the implementation and configuration.
func products(withIdentifiers identifiers: Set<String>, completion: @escaping Completion)

/// Fetches the `SK2StoreProduct`s with the given identifiers.
@available(iOS 15.0, tvOS 15.0, watchOS 8.0, macOS 12.0, *)
func sk2Products(withIdentifiers identifiers: Set<String>, completion: @escaping SK2Completion)

Those are only completion-block APIs. To avoid repetition, an extension on the protocol itself provides an async API, wrapping on top of these 2 methods, regardless of which ProductsManagerType they're being used on.

The hierarchy is now as follows:

• CachingProductsManager
  • ProductsManager
    • ProductsFetcherSK1
    • ProductsFetcherSK2

#1908 gets rid of the now duplicate caching logic in ProductsManager and the fetchers.

Other notes

What makes the implementation a bit more convoluted is the need for a special SK2 method.
This is necessary specifically for TrialOrIntroPriceEligibilityChecker which requires fetching only SK2 products regardless of StoreKit2Setting. In order to guarantee this invariant at compile time through types, a separate cache is maintained with SK2StoreProducts. However, the main caching logic is not duplicated and instead shared for both.

The main tests for CachingProductsManager are simple unit tests that don't make use of StoreKitConfigTestCase.
Because creating SK2 products does require that, I added a separate test class for those.

Future changes

The caching logic is very simple, just like what we had for the fetchers. One missing piece is that if products A and B are requested, and only A is in the cache, this is treated as a complete cache miss.

The fetchers had the same problem, but now that this caching logic is isolated and much easier to test, we can evolve and solve that feature in a more maintainable way.