fix: Enable selecting the '.NET 6 on AL2023' platform when deploying to Elastic Beanstalk on Linux

[ashovlin]

Issue #, if available: #806 (I had tested this quickly when talking to @shruti0085 internally about this issue)

Description of changes:

This widens the string we use to filter Beanstalk Platform options when deploying to Linux, to include the new ".NET 6 on AL2023" platform that was released in October.

Considerations:

• The sort order we're getting back from the service call is what I think we want, so didn't introduce custom sorting like we have for Windows here: https://github.com/aws/aws-dotnet-deploy/blob/03abb117585784ad0fec360e7c5093e37ddf7993/src/AWS.Deploy.Orchestration/Data/AWSResourceQueryer.cs#L627
• Per the docs, the new platform only has .NET 6 installed. However our Beanstalk recipes still allow netcoreapp3.1 or greater: https://github.com/aws/aws-dotnet-deploy/blob/03abb117585784ad0fec360e7c5093e37ddf7993/src/AWS.Deploy.Recipes/RecipeDefinitions/ASP.NETAppElasticBeanstalkLinux.recipe#L36 Deploying an application with an older target (in this case .NET 5) to the new AL2023 platform results in:

  Dec  5 22:10:04 ip-172-31-83-112 web[2147]: You must install or update .NET to run this application.
  Dec  5 22:10:04 ip-172-31-83-112 web[2147]: App: /var/app/current/ASPNet5.dll
  Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Architecture: x64
  Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Framework: 'Microsoft.AspNetCore.App', version '5.0.0' (x64)

However this is true even for the recent AL2 platform versions as well. Unsure if we want to unblock AL2023 initially with this, then better handle the compatibility between the application being deploying and the specific selected platform later? Or try to tackle both issues together

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a8785c3) 61.44% compared to head (86248a3) 61.44%. Report is 1 commits behind head on dev.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## dev #807 +/- ## ======================================= Coverage 61.44% 61.44% ======================================= Files 277 277 Lines 10659 10659 Branches 1484 1484 ======================================= Hits 6549 6549 Misses 3568 3568 Partials 542 542 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ashovlin]

Deploying an application with an older target (in this case .NET 5) to the new AL2023 platform results in:

Dec  5 22:10:04 ip-172-31-83-112 web[2147]: You must install or update .NET to run this application.
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: App: /var/app/current/ASPNet5.dll
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Architecture: x64
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Framework: 'Microsoft.AspNetCore.App', version '5.0.0' (x64)

However this is true even for the recent AL2 platform versions as well. Unsure if we want to unblock AL2023 initially with this, then better handle the compatibility between the application being deploying and the specific selected platform later? Or try to tackle both issues together

We discussed this in today's GitHub triage meeting with @normj , we're comfortable NOT closing this gap at this point. We expect users to be moving off of .NET Core 3.1 and .NET 5 anyway.