Add ParameterInfo of Source to ConverterContext to help IInputConverter implementations

### Description

**Feature request**
When using `IInputConverter` you only get the following information:
- FunctionContext
- Properties (often, if not always empty or unused)
- Source
- TargetType

Having additional information about the `Source` like `ParameterInfo` will give more capabilities and help out special scenario's like when an input has attributes assigned. (Could even lead to not needing a azure custom FromBody?)

**Details**
When dealing with most basic conversions you are fine with the information at hand, but take httptriggers as an example there can be a lot of quirks if you are coming ASP.NET Core.
And you might want to add attributes or need to know a bit about the target parameter to handle them better.

### Motivation

For basic conversions, the current context is sufficient. However, when working with HTTP triggers and aiming for ASP.NET Core–like flexibility when coming from that field, limitations quickly surface.

Example, I’ve implemented a `CustomAspCoreExtendedInputConverter` that mimics Minimal API behavior for conversions and it supports types like `ISpanParsable` and `IParsable`. But when using custom attributes or even existing ones like `FromQuery`, `FromHeader`, or `FromRoute`, the lack of `ParameterInfo` becomes problematic — you cannot get the information from them.

With the existing three it is even easier to notice, if someone tries to use the `Name` property than they will quickly notice that does not work at all, the parameter name must match what you get from the `Uri`, and without access to parameter metadata you cannot fix this in a singular inputconverter, you need to make custom a `FromQuery` version.

This can actually be seen with `FromBody`, a custom dedicated attribute and converter is provided in the Azure sdk because otherwise would not be possible. If `ParameterInfo` were available, similar functionality could be implemented in a singular converter for all of them and mayhap even make the FromBody from the azure sdk obsolete.

##Additional notes##
Regarding `FromQuery`, `FromHeader`, and `FromRoute`: ideally, these should be handled and form a different layer in the code, but didn't get time to go deep enough to where that is all handled in current situation and not even sure if possible due to quirks on how the `FunctionContext` is filled for `HttpRequests`. (like `BindingData` property can be corrupted)
But until that’s addressed, exposing `ParameterInfo` in `IInputConverter` would serve as a practical workaround and unlock much-needed flexibility to get it working from there without a custom variant.

Start by locating IInputConverter and ConverterContext, then trace how HTTP-trigger parameters are represented and passed to converters. Review the existing FromQuery, FromHeader, FromRoute, and FromBody scenarios described in the issue. Done should provide converter access to ParameterInfo while preserving existing conversion behavior and covering the new metadata access.

Written by the indexing model from the issue text.