Extension Proposal: Ash Billing

## What is the purpose of the extension?
High level purpose of the extension.

Provide an easy way for applications to use any billing provider.

Today, we have to leverage an existing SDK in the community, which may or may not be actively maintained to a billing provider's latest API version. Or there isn't one that exists yet and you must handle the integration yourself.

I think Elixir needs a plugin-style billing solution for similar to authentication solutions like `AshAuthentication` and `Ueberauth`. The Ash eco-system seems well poised to help provide such a solution.

Providing such a solution in the Ash ecosystem could be a positive drive for people to choose Ash as their application solution. However, the solution doesn't necessarily have to require an application to use Ash to leverage `AshBilling`.

### Goals
- Choose which billing provider to use
- Choose which billing provider features to use. i.e. subscriptions, usage meters, etc
- Option to choose different billing providers for specific billing features. i.e. Use Stripe for subscriptions, but use Org for usage billing. This is to keep compilation time down. Some providers have extensive APIs with endpoints the user may not care about. Stripe, for example, has a ton of functionality that most SaaS apps won't use. There's no need to incur extra compilation time for generated modules that will never be used.
- Choose whether to store billing provider data in your data layer and sync with billing provider or do all CRUD via the billing provider's API. i.e. The application may want to handle cases where the billing provider is unavailable
- Billing provider integrations are provided by introspecting the provider's Open API spec to ensure the latest provider's API features are always supported as resources. Like the inverse of `ash_json_api` for generating an Ash app's spec.

- Initial Billing Providers
- [Stripe](https://stripe.com)
- [Polar](https://polar.sh) - Likely easiest for a POC since the API is relatively small and focused on SaaS

## How would it extend the DSL?
Add an example of the DSL configuration this extension might add.

I don't know how this DSL would look at the moment. I can see this starting off as an extension to generate a DSL from open API specs that will be used to generate billing providers integrations for AshBilling. Then AshBilling provides the universal DSL to interact with any billing provider.

I'd like to see what others in the community think about the idea and what a unified billing DSL could look like.

No files, tests, or entry points are named. Start by reviewing the proposed goals, provider choices, and open questions about the DSL. The work is ready to implement only after the community agrees on a concrete unified DSL and initial provider scope.

Written by the indexing model from the issue text.