Make ApiExplorer for minimal APIs trim-compatible

[captainsafia]

Part of #56023.

This PR removes the trim warnings originating from Mvc.ApiExplorer when used on an application using minimal APIs + OpenAPI. The bulk of these trim warnings originate from the use of ParameterBindingCache to determine the status of parameters on a route handler and CoerecedAwaitable to unwrap awaitable response types. The use of unbounded reflection from these types is replaced by the introduction IParameterBindingMetadata and updates to RDF and RDG to produce this metadata as they analyze endpoints.

This PR also sets ProducesResponseType metadata at the framework level for response types that are unwrapped from an awaitable to replace the use of CoercedAwaitable in EndpointMetadataApiDescriptionProvider. There's also some ✨ surgical ✨ changes to the ApiDescriptionProvider implementation to work around issues are the ambiguity between typeof(void) as a null-type versus an explicitly set type in the ApiResponseProvider.

Specific changes include:

• Update EndpointMetadataApiDescriptionProviderTests to call into RequestDelegateFactory so we can pick up metadata inserted by the code generation layer from ApiExplorer
• Emit ParameterBindingMetadata class in source generated code and add ParameterBindingMetadata to all parameters that are discovered during source gen
• Update ApiDescriptionProvider implementation to use parameter-binding metadata as the source of truth for parameters on an endpoint instead of MethodInfo.GetParameters
• Set typeof(string) for ProducesResponseTypeMetadata inferred by the platform for string-types to avoid falling into traps around typeof(void) vs. null as unset response type

[eerhardt]

The trimming infrastructure related changes LGTM

[captainsafia]

After adding the NativeAoT test project in a636d4a, I realized there is another layer of trim-incompatible issues that we are running into.

In addition to relying on the ParameterBindingMethodCache to resolve info related on parameters at the top-level EndpointMetadataApiDescriptionProvider layer, we also end up bringing in this dependency when we set ModelMetadata on the ApiParameterDescription, and ApiResponseTypes.

aspnetcore/src/Mvc/Mvc.ApiExplorer/src/EndpointMetadataApiDescriptionProvider.cs

Line 194 in 6548eba

ModelMetadata = CreateModelMetadata(paramType),

aspnetcore/src/Mvc/Mvc.ApiExplorer/src/EndpointMetadataApiDescriptionProvider.cs

Line 367 in 6548eba

apiResponseType.ModelMetadata = CreateModelMetadata(apiResponseType.Type);

aspnetcore/src/Mvc/Mvc.ApiExplorer/src/EndpointMetadataApiDescriptionProvider.cs

Line 406 in 6548eba

ModelMetadata = CreateModelMetadata(responseType),

CreateModelMetadata returns an EndpointModelMetadata:

aspnetcore/src/Mvc/Mvc.ApiExplorer/src/EndpointMetadataApiDescriptionProvider.cs

Lines 438 to 439 in 6548eba

	private static EndpointModelMetadata CreateModelMetadata(Type type) =>
	new(ModelMetadataIdentity.ForType(type));

EndpointModelMetadata extends MVC's ModelMetadata which takes a dependency on ParameterBindingMethodCache yet again:

aspnetcore/src/Mvc/Mvc.Abstractions/src/ModelBinding/ModelMetadata.cs

Lines 23 to 32 in 6548eba

	public abstract class ModelMetadata : IEquatable<ModelMetadata?>, IModelMetadataProvider
	{
	/// <summary>
	/// The default value of <see cref="ModelMetadata.Order"/>.
	/// </summary>
	public static readonly int DefaultOrder = 10000;
	private static readonly ParameterBindingMethodCache ParameterBindingMethodCache
	= new(throwOnInvalidMethod: false);

This dependency was introduced when we added support for a TryParseModelBinder in MVC (see 3817558).

So there's another layer of changes that need to be made here to quarantine the ParameterBindingCache out of the shared ModelMetadata implementation, use the information we're already storing in IParameterBindingMetadata for MVC scenarios, and hopefully not break the controller-based APIs. We may also end up needing to leverage a feature switch in here somewhere...

[eerhardt]

The trimming related changes LGTM. Just one minor comment that can be addressed in a follow-up if you don't want to reset CI.

[eerhardt]

Can we add a Justification here? same as:

aspnetcore/src/SignalR/server/Core/src/Microsoft.AspNetCore.SignalR.Core.WarningSuppressions.xml

Line 9 in 9503913

<property name="Justification">This warning is left in the product so developers get an ILLink warning when trimming an app when Microsoft.AspNetCore.SignalR.Hub.IsCustomAwaitableSupported=true.</property>

[captainsafia]

/backport to release/9.0-preview7

[github-actions]

Started backporting to release/9.0-preview7: https://github.com/dotnet/aspnetcore/actions/runs/10050522403