Support Service level release plans

**Requirement: Support for service level release plans**

Related to - https://github.com/Azure/azure-sdk-tools/issues/6639

**Scenario 1**
- A new service has not completed Cloud Ring Onboarding (usually because the business plan is still not complete/approved) so they are blocked from creating the product entry in service tree.
- Even though the team has not completed Cloud Ring Onboarding, the engineering team has not stopped working. They have to continue to work on the deliverables for Public Preview. So they need to engage us to begin working on designing and authoring their REST APIs and work to release their SDKs.
- **Issue** Without a product entry in service tree, service teams are unable to create a release plan.
- Without a release plan service teams must rely on our docs, scheduling info meeting(s), reaching out in teams, etc. So just like before (they are lost not sure where to go next).
- The data will not be in ADO because there is no epic-product, no release plan, etc. Most of these teams would be in scope for TypeSpec onboarding.

**Scenario 2**

- There is work done post-GA by service teams that is at the service level, not the product level.
- For example, a new ARM RP version spans across all of the products that use that RP. The new RP results in a new ARM REST API version that enables all of the products.
- **Workaround used now:** As long as teams have a product mapped in service tree, I am asking them to just choose one product and use it for a release plan.
- **Issue:** This is not reflective of what they are doing b/c every product will be enabled by the new RP version/new ARM REST API version but only one product has release plan. So our ADO data will reflect that one product released a new API version and the other products will not be linked to that release plans.

**Related requirement: Support mulit-product release plans**

- We can open a new issue but noting here because the resolution could potentially cover this requirement as well. It is similar to Scenario 2 only instead of all products it is a subset of products.

**Scenario 3**

- Service has multiple products launching and they will be updating the same API version, then the someone at the service level is going to be releasing the new SDK version that will be for all of the products launching who have already updated the API Spec.
- **Workaround used now:** I am asking service teams to just choose one product and use it for a release plan to validate API readiness for the PR and release the new SDK versions.
- **Issue:** The tracking of APEX requirements has to be manual for all of the products, except the one that was used for the release plan. Also, Our ADO data will reflect that one product released a new API version and the other products will not be linked to that release plans. So our ADO data will be incorrect as well.