Rename assignable property in User to be applicable

What does this MR do and why?

Renames assignable property on User to be applicable since this property is about whether user is applicable for add-on rather than whether add-on an be assigned to them (add-on may not be assignable if all add-on seats are used up).

Related discussion around property rename: https://gitlab.com/gitlab-org/gitlab/-/issues/411954#note_1494438903

Note: The API changes are in progress, this MR is to make sure when the API is ready, frontend flows smoothly.

Related to #420010

Screenshots or screen recordings

How to set up and validate locally

1. Customers Dot needs to be setup in order to view the billing page for a group

2. Start GDK in SaaS mode GITLAB_SIMULATE_SAAS=1 gdk start

3. Create a Group

4. Enable enable_hamilton_in_usage_quotas_ui FF (globally, or for your group)

5. Buy a Subscription for your group from Settings > Billing

6. Visit /groups/<your-namespace-name>/-/usage_quotas#seats-quota-tab

7. Purchase add-on for namespace

   # Get the desired namespace
   namespace = Namespace.last
   # Create an add-on
   add_on = GitlabSubscriptions::AddOn.find_or_create_by!(name: "code_suggestions") {|e| e.description = "Test"}
   # Purchase add-ons for the namespace
   add_on_purchase = GitlabSubscriptions::AddOnPurchase.create!(
     add_on: add_on, namespace: namespace, expires_on: 1.month.from_now, quantity: 2, purchase_xid: 'A-S0001'
   )

8. Add this snippet here to enable add-on assignment. This enables the add-on assignment for the first user in the list (as per applicable value).

       state.members[0].add_ons = { assigned: [], applicable: [{ name: 'CODE_SUGGESTIONS' }] };

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.