Make StoreProduct an interface

[swehner]

Checklist

• [X] If applicable, unit tests - no new unit tests, Ran all tests
• [X] If applicable, create follow-up issues for purchases-ios and hybrids - shouldn't be affected, no interface change or new functionality

Motivation

For supporting BillingClient v5 we'll need to return different flavors of StoreProduct referencing a ProductDetails and offerToken object. Given we necessarily don't need to expose any of this information we want to keep StoreProduct as an interface.

Description

Change StoreProduct from data class to interface. Provide a StoreProductImpl. New sublclasses for BC5 will be provided in following PRs: see https://github.com/RevenueCat/purchases-android/pull/628 for current discussions with Maddie and proposal to implement BC5.

[vegaro]

We had a similar problem with Amazon and Google, where there were some fields that were only available in Google and not in Amazon product, or the other way around. Like for example coinsRewardAmount, which is only available in the Amazon product.

To solve it, we created StoreProduct as an abstract class with a bunch of common fields (and some that we already had in Google's product) and created two extension functions StoreProduct.amazonProduct and StoreProduct.skuDetails that return the original Amazon or Google object.

We did it this way to offer a way to access the original object and also to not have to be constantly casting between AmazonStoreProduct and GoogleStoreProduct. And possibly other reasons I don't remember right now. That said, I am not married to that option, but that's what we decided to do.

I am not sure if I understand exactly what's the intention of making it an interface instead. Is it to offer a way to access ProductDetails and offerToken? Can you provide an example of how devs would access it after this change and the subclasses PRs are merged? Just to get a better idea of how the final code would look like.