Deployments Design results in complex Pipelines/workflows which duration is too long

**Is your feature request related to a problem? Please describe.**
If you create the App from the Portal, you will get a default Production deployment.
In real life most of the customers uses IaC such as TF or Azure Bicep.

**Describe the solution you'd like**
A clear and concise description of what you want to happen.

When a customer create the App with IaC and then deploys to Staging using ASA GitHub Action (providing all correct parameters including deployment name) it fails with :
Error: Action failed with error: deploymentName cannot be null or undefined.

==> this is because the Staging deployment needs a Production deployment as a pre-req to get the CPU&RAM sizing.
==> from scope wise, GHA doesn't offer feature parity thing with other customer interfaces like portal, CLI and the current scope is mainly on deployment part.

But if you use the GHA to deploy to Production, the first time it will fails saying that a Staging Deployment is required first, resulting in circular dependencies issues.

IMHO, the GHA should support RAM & CPU, this is the only way to get GHA to work. Also the sizing could be eventually different in Prod and Staging.

**Describe alternatives you've considered**
Then the only solution is to design a much more complex workflow using CLI only.
My [GH Workflow sample](https://github.com/ezYakaEagle442/azure-spring-apps-petclinic-mic-srv/blob/azure/.github/workflows/build-deploy-ui-staging-CLI.yml#L274) takes 5 minutes and more than 200 lines of code just to deploy 1 App whereas it would take 1 line and 30s to deploy it to AKS.

The reason why it is complex is that you need to run many CLI commands to check if the deployment does already exist or not, to create it if it does not exist, then verify all other deployments, check if it is already a Staging or a Production one.

WORKAROUND :

1. Use CLI a first-time as a 'pre-flight' running 'az spring app deploy' that would create a default PRODUCTION deployment named 'default' for each App
2. Accept this naming convention and do not rename the default PRODUCTION deployment named 'default' for each App
3. You are then able to use the GHA , this would then shorten the Workflow length & complexity
4. Once the App runs in Production, you can delete the Staging deployment
- pros: that optimizes cost
- cons: but you do not have anymore a Deployment to rollaback to

Other consideration to test , use CLI to create a Staging deployment with a different RAM&CPU sizing compared to Prod :
```sh
az spring app deployment create \
--name $DEPLOYMENT_NAME \
--app ${{ env.API_GATEWAY }} \
--service ${{ env.AZURE_SPRING_APPS_SERVICE }} -g ${{ env.RG_APP }} \
--instance-count ${{ env.DEPLOYMENT_INSTANCE_COUNT }} \
--cpu ${{ env.DEPLOYMENT_CPU }} \
--memory ${{ env.DEPLOYMENT_MEMORY }} \
--version ${{ env.DEPLOYMENT_VERSION }} \
--runtime-version ${{ env.DEPLOYMENT_RUNTIME_VERSION }} \
--skip-clone-settings
```

**Additional context**

Doc links :
- [Blue-green deployment strategies in Azure Spring Apps](https://learn.microsoft.com/en-us/azure/spring-apps/concepts-blue-green-deployment-strategies)
- [Use Azure Spring Apps CI/CD with GitHub Actions](https://learn.microsoft.com/en-us/azure/spring-apps/how-to-github-actions?pivots=programming-language-java)
- [other B/G Workflows sample](https://github.com/Azure-Samples/azure-spring-cloud-blue-green/blob/main/.github/workflows/blue-green-deploy.yml)
- [ASA Action from GH market place](https://github.com/marketplace/actions/azure-spring-apps)
- [https://github.com/dantelmomsft/spring-petclinic-microservices/tree/master/.github/workflows](https://github.com/dantelmomsft/spring-petclinic-microservices/tree/master/.github/workflows)