[subs 2] Add purchase endpoints

[rafaelbsky]

(supersedes #3156 and #3160)

This PR adds 4 endpoints to bsky and the necessary underlying calls to bsync to implement them:

1. app.bsky.purchase.getSubscriptions:
   1. Used to fetch the active subscriptions for a user. It is called roughly once per app load.
   2. This calls bsync, which calls RevenueCat.
2. app.bsky.purchase.getFeatures:
   1. Used to fetch what paid features the client app should enable for the user (example: enable selecting a custom color).
   2. Reads cached data from the dataplane, doesn't reach out to RevenueCat.
   3. The dataplane read path is still to be done in a future PR. It will be done through bsync providing a scan... GRPC endpoint that the indexing infrastructure will call. That scan... method will serve data that bsync either obtained by being triggered by a webhook event, or by being called in the app.bsky.purchase.refreshCache flow.
3. app.bsky.purchase.getSubscriptionGroup:
   1. This is used when the user navigates to the screen to subscribe and we need to show the possible options (depends on the platform, etc).
   2. This calls bsync. In this case, bsync doesn't need to call RevenueCat, it replies with in-memory data. The return data here is basically just a configuration. Still, we do it in bsync so bsky can remain completely agnostic regarding any purchase-related configuration.
4. app.bsky.purchase.refreshCache:
   1. Use by the user (and possibly support agents) to refresh the dataplane cache. Refreshing this cache possibly affects the data returned by app.bsky.purchase.getFeatures (if that was out-of-date, this is what makes it be refreshed).
   2. This calls bsync, which calls RevenueCat.

You can skip the codegen commit when reviewing.

Notable points:

1. bsky knows nothing about RevenueCat.
2. bsync knows about RevenueCat, but only in a few contained points.
   1. In the webhook listener, which is RevenueCat-specific.
   2. Some configs have "revenue cat" in their names, as they are used to build the RevenueCatClient.
   3. Previously we only had RevenueCatClient, which was used in multiple places in bsync. In this PR I abstracted RevenueCatClient away into a PurchasesClient, that does the mapping between RevenueCat formats and our formats. PurchasesClient is now called in multiple places instead of RevenueCatClient. Note also that PurchasesClient is what does the mappings between entitlements, products, etc. Since those rely on configs for the Stripe identifiers, I preferred to put that logic inside a class than in individual functions (like it was in the POC), so I can inject the config.

[devinivy]

Looking great, just left a handful of small comments.