Improve overload resolution in error scenarios for better source-generator experience

Use this csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

</Project>

and

var app = WebApplication.CreateSlimBuilder().Build();

// MapGet here binds correctly to the overload that takes RequestDelegate.
app.MapGet("/good", async (HttpContext ctx) =>
{
    await ctx.Response.WriteAsync("Hello");
});

// MapGet here binds to the overload that takes Delegate instead of RequestDelegate.
// While the lambda body contains an error, it seems that the compiler should still be
// able to understand that the parameter is HttpContext and return type is Task.
// So, inferring RequestDelegate should be possible.
app.MapGet("/bad", async (HttpContext ctx) =>
{
    // This line causes build error.
    // In the real scenario, the scenario involves two source generators:
    // 1. STJ source generator (the code here calls into STJ-generated code)
    // 2. RequestDelegateGenerator (generates interceptor call but only for the System.Delegate case).
    // The compiler binds this incorrectly to System.Delegate instead of RequestDelegate.
    // So, an interceptor is incorrectly generated by RequestDelegateGenerator.
    await ctx.Response.WriteAsync(ctx);
});


await app.RunAsync();

I expect to have better overload resolution even for error scenarios like this.