Namespace Select should take advantage of v-model

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Our [`NamespaceSelect` Component](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/purchase/components/namespace_select.vue) helps us in managing the namespaces selection nicely. There are a couple of things we can improve though:

1. its API forces the parent to manually manage the state
1. its API seems to have knowledge the parents will use the data for some other actions
1. its usage from the parent components is not always consistent

|An example from Storybook|
|-|
|![Screenshot_2021-08-04_at_14.03.07](/uploads/ddb754f9c2d21767a70e3b313756b474/Screenshot_2021-08-04_at_14.03.07.png)|

### Proposal

To help with the improvements above, let's make the `NamespaceSelect` `v-model`-ready by [configuring it](https://vuejs.org/v2/api/#model):
- using `change` event to propagate the selection, which is the newly selected `namespace`:
- `value` as the prop for the selected namespace
- `initialNamespaceId` would be good to stay only as a non-required prop to define the initially selected id

A selector is a quite common scenario where a `v-model` would turn useful to avoid 1). Also, a `v-model`-enabled component can support divergent usages (like the ones specified in the [notes below](#notes)), but should not be designed based on the assumption of such usages.

### Notes

The namespace selection is sometimes used to perform other operations as a consequence of the selection (see examples of usage). While this might not be ideal, changing this approach would result in a much larger scope. To circumvent this, we can rely on the usage of `watch`:

```js
watch: {
    selectedNamespace() {
      // operation to perform
    },
  },
```

In at least one case, the `change` event is just proxied. This is a valid approach for `v-model`-enabled components as well. We can keep it as-is.

### Result

Having this way, we can avoid manual handling of data mutation in some of the parent components using it. Here's a list of where it's used:

- [New GitLab Subscription Form](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/subscription/components/new_gitlab_subscription_form.vue)
- [Change Namespace Form](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/subscription/components/change_namespace_form.vue)
- [Purchase Details Card](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/purchase/components/purchase_details_card.vue)

### Next steps (if any)

After having introduced `v-model` capability for the component, tag `@fulfillment-group/fe` on the Issue to notify them of the change and/or share the news in `#s_fulfillment_engineering`.

Story points: 3.0