Create BillingAccountMembership when processing Zuora Callouts

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4795, the `BillingAccount` and `BillingAccountMembership` should be created when a purchase originates from CustomersDot (ie. self service purchase).  However, there are still places where the `BillingAccount` and/or `BillingAccountMembership` should be created outside of this workflow.

- Sales-assisted purchases
- Renewals

In these cases, CustomersDot processes the callout from Zuora in order to update the `Customer` (to be renamed `User`) and provision the subscription.  The Zuora callout code in CustomersDot needs to be updated to handle `BillingAccount` and `BillingAccountMembership` creation.

### Proposal

In this issue, the `FindOrCreateCustomerService` should be updated to create an `BillingAccountMembership` for a `Customer` (to be renamed `User`) when the `zuora_account_id` attribute is present.  It should also consider creating the `BillingAccount` if it doesn't already exist.

If an existing `Customer` is found, but the `Customer` is not associated with the `BillingAccount` matching `zuora_account_id`, a new `BillingAccountMembership` (and potentially new `BillingAccount`) could be created.  

We've decided for this first iteration (https://gitlab.com/groups/gitlab-org/-/epics/8950), that we want to ensure only one `BillingAccountMembership` for a Customer.  This is to keep the same behavior as before, allowing us to step into the new data architecture and roll out the changes more effectively.  See the description in https://gitlab.com/groups/gitlab-org/-/epics/8950#purpose for more info.

#### Feature flag

This logic will be feature flagged in the short term using [the `:account_data_persistence` flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/171/edit). Here is the rollout issue for it: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5060+. Once we confirm the data is being created as expected and doesn't have any negative effects with the existing creation behavior, we will remove this feature flag.

As this is just creating data in the new models but not using it yet, we shouldn't need to use the `:account_data_structure` [feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/160/edit) for this logic. Eventually, the code setting `customer.zuora_account_id` will be removed but for now both will be set. This will allow us to roll out changes more efficiently without worry of breaking existing functionality.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Tests should be created/updated to account for this change.  Test to ensure that:

- Likely Model and Controller specs (to ensure proper validation and relation)
- UI specs

Story points: 3.0