Reduce friction in the Web/Worker/Database on Azure Container Apps scenario

[This issue was copied from the planning repo]

Establish baseline effort score for .NET 6 ASP.NET Core customers to create a Worker/Web app that makes use of 2 different Azure messaging services when wired up with Visual Studio Connected Services for a specific, opinionated scenario. We'll first tackle this scenario with Azure Storage Queues, but could roll in Event Grid or other providers if time permits.

The app should consist of the following components:

- [ ] A minimal API that drops messages it receives into an Azure Storage Queue for asynchronous processing by the worker service
- [ ] A front-end ASP.NET Core app providing the user interface to the API
- [ ] A Worker Service project that runs as a queue-watcher, processing incoming messages and saving them to a SQL DB using Entity Framework Core
- [ ] A SQL database storing the data permanently
- [ ] An Azure Storage Queue receiving the API's posts
- [ ] Application Insights telemetry so the customer can see an Application Map of the entire flow of traffic at the end (this is the "visual goal" for the experience)
- [ ] Ideally we use service authentication and not connection strings in this e2e

We'll provide customers/tester the end-to-end and gain insight into the slow parts, complex parts, and gain insight into how the experience could be improved upon.

We'll also provide our testing team the end-to-end as a scenario test they can run on intervals so we can keep tabs on how changes in the APIs and SDKs impact the experience and resources available for customers trying to achieve it.