Support standard ASP.NET Core applications without Functions-specific attributes

#### What problem would the feature you're requesting solve? Please describe.
Currently, Azure Functions requires decorating HTTP endpoints with Functions-specific attributes ([FunctionName], [HttpTrigger]), which creates vendor lock-in and prevents using standard ASP.NET Core controllers.

This forces developers to choose between:
1. Standard ASP.NET Core (portable, but no Functions deployment)
2. Functions-specific code (serverless, but locked to Azure)

#### Describe the solution you'd like
Azure Functions runtime should support deploying standard ASP.NET Core applications without code modifications. The runtime should:

1. Detect standard ASP.NET Core projects (Program.cs, Controllers)
2. Host Kestrel within the Functions runtime
3. Route HTTP triggers to the ASP.NET Core pipeline transparently

Configuration (scaling, billing, lifecycle) remains in infrastructure (host.json, ARM templates), NOT in code.

#### Describe alternatives you've considered
- Container Apps: Works but loses Functions-specific features
- Adapter pattern: Adds boilerplate and maintenance burden
- AWS Lambda Web Adapter: Already solves this problem

#### Additional context
.NET Core's value proposition is portability and open standards.
Requiring Functions-specific attributes contradicts this philosophy.

The same code should deploy to:
- Azure Functions
- App Service
- Container Apps
- IIS
- Standalone Kestrel

Deployment target should be infrastructure concern, not application code.

Start by reviewing the mentioned Program.cs and Controllers entry points, then examine how host.json and ARM templates define deployment configuration. Trace how Kestrel and the ASP.NET Core pipeline would connect to the Functions runtime. Done means a standard ASP.NET Core application can deploy without Functions-specific attributes while retaining the requested infrastructure-managed behavior.

Written by the indexing model from the issue text.