Azure functions HttpTriggers Json deserialization failure should return BadRequest instead of Internal Server error

### Description

**Feature request**
When using HttpTrigger and a Json de-serialization fails there is a `InvalidOperationException` and it will result in `Internal Server Error`.
When you compare it to ASP.NET Core, especially when migrating from it to azure functions, this is an unexpected behavior as there it would result in `BadRequest` with `ValidationProblemDetails`.

**Details**
This example uses ASP.NET Core integration, however same happens with native one.
Assumed: `JsonSerializerOptions` has been set to use JsonStringEnumConverter.
```C#
public class HttpFunction
{
[Function("Sample")]
public async Task SampleAsync(
[HttpTrigger(AuthorizationLevel.Function, "post", Route = "sample")] HttpRequest request,
[FromBody] Sample model
)
{
return Task.FromResult(new OkResult());
}
}
public class Sample
{
public SampleEnum Value { get; set; }
}
public enum SampleEnum
{
A,
B
}
```

When invoked with a json payload that has a value not in the enum get an exception because "Error" is not the deserialization, with the message `System.InvalidOperationException: The Json value could not be converted ....`
```json
{
"value":"Error"
}
```

**Additional Information**
A few points regarding the feature request:
- Because it throws `InvalidOperationException` a middleware cannot help determine if it was a json exception without interpreting the message.
- An unique exception only thrown by the `FromBodyConversionFeature` would be needed, because a non-unique one like `JsonException` or so just means you still have to find out if the input deserialization is the cause or some other layer that leaked.
- The `FromBodyuConversionFeature` has a model state with results, so even a `BadRequest` with proper `ValidationProblemsDetails` would be expected.
- During an attempt to create and use a custom `IInputConverter` and a copy of `DefaultFromBodyConversion`, it was noticed that ussing `ConversionResult.Failed(exception)` actually has no use, as the `GeneratedFunctionExecutor.g.cs` just perform as `BindFunctionInputAsync` and even if that returns a failed type it means the result is `null`. (Seems weird)
- It is not only with in regard with the `JsonStringEnumConverter`, but will all forms of json that fail, it is just used in the example as it is the fastest way to reproduce.

Currently the only way to have this into a `badrequest` is either:
- Not use `FromBody` and deserialize manually from HttpRequest(Data), however that does feel like a step back
- Create custom `FromBodyAttribute` and either catch the exception from `FromBodyConversionFeature` to a custom one or have copy from `FromBodyConversionFeature` and have it in there thrown
- Replacing `IFromBodyConversionFeature` in FunctionContext features is also an option if possible, though not checked nore sure about side effects

The first option would mean that you potentially have to do that for a lot of http function triggers, while it would feel more out-of-box feature.
The second/third are an option, however you are very dependent on what the sdk will do and very upgrade dependent breaking.

Start with FromBodyConversionFeature and IFromBodyConversionFeature, then trace how conversion results flow through GeneratedFunctionExecutor.g.cs and BindFunctionInputAsync. Compare the native and ASP.NET Core integration paths; done means malformed JSON for an HttpTrigger produces BadRequest rather than Internal Server Error, with the conversion cause distinguishable from unrelated failures.

Written by the indexing model from the issue text.