Detect services based on service provider

[davidfowl]

• Added an IServiceProvider argument to RequestDelegateFactory.Create
• As a final fallback, try to detect services from the DI container before falling back to body behavior.

There are some gotchas:

• We can't do this at compile time, it's a runtime only feature (for the future). Not a big deal, we know how to handle this for AOT scenarios in the future.
• There are side effects. Your object will get created once to "test" if it's indeed a service. We could build an optional capability into the DI container for this to avoid the activation.
• As part of instantiating the object, we need to dispose it. If this object has a scoped lifetime and is IAsyncDisposable only, this will currently throw an exception.
• Any ambiguity can be avoided by using the [FromServices] attribute and by being explicit

It cleans up this scenario nicely:

app.MapGet("/todos", async (TodoDbContext db) =>
{
    return await db.Todos.ToListAsync();
});

app.MapGet("/todos/{id}", async (TodoDbContext db, int id) =>
{
    return await db.Todos.FindAsync(id) is Todo todo ? Ok(todo) : NotFound();
});

This PR is now blocked on dotnet/runtime#53919

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[davidfowl]

@halter73 feel free to review this on Monday. I'm merging all of the PRs I've had open to get them in the end to end build for further testing.