Update ActionTypeGenerator to determine actions based on business logic

<!-- 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

[`ActionTypesGenerator`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d482c68e02279a049e34766362baa76efd869d95/app/services/zuora/orders/amendment/action_types_generator.rb) currently determines applicable actions types for a request on an individual basis.

This approach was found to have the following two shortcoming:

1. The order (or priority) in which the order actions were sent to Zuora may not be appropriate
   For e.g. when upgrading a self-managed subscription plan during renewal and true-ups are added, `AmendmentSubscriptionService` currently generates amendment in the following order:

   - Remove main product
   - Add main product
   - Renew subscription
   - Add true-ups

  In the current implementation of `ActionTypesGenerator`, it will generate these order actions in the following order:

   - [Remove main product](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d482c68e02279a049e34766362baa76efd869d95/app/services/zuora/orders/amendment/action_types_generator.rb#L39)
   - [Add main product](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d482c68e02279a049e34766362baa76efd869d95/app/services/zuora/orders/amendment/action_types_generator.rb#L43)
   - [Add true-ups](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d482c68e02279a049e34766362baa76efd869d95/app/services/zuora/orders/amendment/action_types_generator.rb#L65)
   - [Renew subscription](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d482c68e02279a049e34766362baa76efd869d95/app/services/zuora/orders/amendment/action_types_generator.rb#L49)

   Given Zuora processes Order actions in the order in which it is sent, it is critical to maintain the priority of the action types:

   ![Screen_Shot_2022-09-15_at_5.37.46_PM](/uploads/27c5cbdbb32ec750f4870b120b24fbf1/Screen_Shot_2022-09-15_at_5.37.46_PM.png)

2. In the event when an order action type is twice: e.g when updating main product, and when updating options product OR when upgrading to a new product and adding true-ups. The determination logic is replicated in both `ActionTypeGenerator` and in `ParamConstructor`.


### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In order to resolve these two issues, action type in `ActionTypesGenerator` can be determined using business logic. `ActionTypesGenerator` returns a list of action types that are specific to CDot, such as `add_main_product`, `add_true_ups`, `remove_main_product`, `update_support_options` and so on.

Crete a mapping of these business driven action types with that of Zuora before invoking Orders API.


### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0