[SM] Use term end date for all ramp enabled subscription licenses

### Background
Historically, all ramp licenses were generated for term start date + 1 year. With Zuora Ramps, we are establishing automated provisioning of licenses for the entire ramp subscription period, so this shortened term is no longer necessary.

With the Zuora workflow being setup by EntApps, callouts will be sent from Zuora to CDot whenever a new ramp interval starts in order to provision additional seats at the start at each ramp interval.

### Problem

As discussed in this thread https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4295#note_1189876785, ramped subscriptions where cloud licensing is enabled have licenses generated for the full subscription term.  For example, if a subscription has a 3 one year ramps, the full subscription term is 3 years, and therefore has a license generated for the full 3 years.  If the quantity changes when a new ramp begins, a callout will be sent to CDot to generate a new license with the new quantity for the full term.

The logic for determining the license end date can be [found here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ec6b3cc9dca0e511568ba86c0b3d6db99cfdcd19/app/models/concerns/license_creation.rb#L15).  Currently, this logic only applies to Subscriptions with cloud licensing enabled, but we need it for Subscriptions with legacy licenses too.

### Proposal

Update the `LicenseCreation#license_end_date` method to determine the license end date consistently for all ramp enabled subscriptions, using the term end date.


### Proposal Summary

Generate the initial license for a ramp subscription for the entire 3 year subscription term (and then send a new license for only the additional users at the start of each year).

Reason for this proposal, rather than generating the initial license for 1 year and sending a new license for the full user amount at the start of each year:
1. We are moving towards generating all licenses for the entire subscription term, not just ramps ([example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4816)), as it requires less manual intervention. Option 2 is consistent with this motion.
1. There is no risk of the customer losing access entirely if there is any provision failure at the start of years 2/3 - only not having access to the additional seats. Seems this could result in fewer support escalations.
1. This was the plan with cloud license enabled subscriptions, so to me it makes sense to keep both types consistent.

### Proposal Details
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4879 updated the existing license end date logic to generate ramp enabled licenses for the full subscription term for cloud enabled subscriptions _only_. We should remove this condition on cloud enabled by updating [this line](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ec6b3cc9dca0e511568ba86c0b3d6db99cfdcd19/app/models/concerns/license_creation.rb#L15).

I think we want to update this:
> `# If Subscription is cloud and (reconciliations or ramps enabled), we issue it for the full term`

To this:
> `# If Subscription is (cloud and reconciliations) or ramps enabled, we issue it for the full term`

Side note, once https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4816 is implemented, the logic will actually be:
> `# If Subscription is cloud or ramps enabled, we issue it for the full term`

### Result
All ramp licenses (whether cloud or not) are created for the full term.

Story points: 1.0