[Release Planner] Add steps on Validating GitHub Aliases & Service Label Approval Process

I believe the Release Planner currently is missing a step for team's onboarding with the Azure SDK Team that need to get a service label approved for their libraries.

## Current Process
When partner teams are opening their first PR to merge in code for their libraries, they will add entries to our CODEOWNERS files following the docs here: https://eng.ms/docs/products/azure-developer-experience/develop/supporting-sdk-customers/codeowners

The PR CI (`codeowners-linter`) usually catches 2 issues.
1. The aliases the PR author entered in the CODEOWNERS file are not valid
2. The Service Label the PR author entered does not exist.

Issue 1 is easy to fix. The PR author just needs to make sure the aliases they are adding are public members of both the Microsoft and Azure GitHub Orgs and they have write permissions to the SDK repos. This information is already in our Eng Hubs docs [here](https://eng.ms/docs/products/azure-developer-experience/onboard/access) in the "Request access to Azure REST API and SDK repositories" section.

Issue 2 requires they go through the Service Label Approval Process. Which just requires them to reach out to me (@ronniegeraghty) to discuss the label. I ask the partner team to send me the name of the libraries they are releasing, a link to their API Spec, and a piece of public documentation on their service. Then when the partner team and I come to an agreement on the label, I add the label to our [`common-label.csv`](https://github.com/Azure/azure-sdk-tools/blob/main/tools/github/data/common-labels.csv) file and push it out to all our repos using the [`Sync-AzsdkLabels.ps1`](https://github.com/Azure/azure-sdk-tools/blob/main/tools/github/scripts/Sync-AzsdkLabels.ps1) script.

Once the aliases used in the CODEOWNERS file have the proper permissions and the label has been pushed to the repo the CI will pass. _Note: Sometimes it may take 24 hours for the CI to see the label has been created._

The Label approval process usually takes anywhere from 2-4 days, depending on how quickly the partner team and I come to an agreement.

## Problem Statement:
A partner team has reached out asking if the label approval process could happen earlier in the onboarding process, so the label approval doesn't hold up their PR. They suggested during the namespace approval process.

They also asked if the label approval process could be automated in the Release Planner.

## Possible Solution:
Add a step in the onboarding checklist to go through the current Label Approval process. This will have teams go through the process much earlier, so by the time they get to creating their PR, they will have an approved label. This may be the easiest solution, but it does not automate the process or keep the process exclusively in the release planner.

## Required Information for Label Approval
1. Library Names
2. Service API Spec
3. Public Docs on the Service _(These are used to verify the approved public branding for the service. Any other proof of the approved brand name for the service would also work.)_

## Possible Blockers
If the partner teams go through the Service Label approval process during onboard to the SDK team, their service may not be public yet, meaning we cannot push their label out to our public repos yet. We would need to approve the label, record the approval, then wait until the service is ready to go public.

Currently the [`Sync-AzsdkLabels.ps1`](https://github.com/Azure/azure-sdk-tools/blob/main/tools/github/scripts/Sync-AzsdkLabels.ps1) script does not support only pushing labels out to a subset of repos. So, if a service hasn't gone public yet and the partner team is working in our private repos, we would not be able to automate the push of the Service label to only private repos.