Explicit parameter binding

[KathleenDollard]

Significant updates to binding so method binding and model binding use the same logic and same code paths.

Draft due to rebase issues.

[jonsequitur]

We don't want people to create instances of this.

[KathleenDollard]

It does not appear that BoundValue escape the context of System.CommandLine. I think we should deliberately consider the needs of any application models that need something other than to connect a ValueSource to a Option/Argument ahead of any evaluation. IOW, we may need this public in the future, but it does not appear that we need it public now.

This is probably part of a broader discussion of checking our public API surface.

[jonsequitur]

These shouldn't be necessary, correct?

[KathleenDollard]

I think it is needed, although it might not be in the right place. That extension method drives the following syntax:

            handler.BindParameter(parameter, argument);
            command.Handler = handler;

The handler is managed as an ICommandHandler, so putting the method on the interface isn't sensible due to the ParameterInfo/PropertyInfo. Thus, an extension method seemed the right approach.

[KathleenDollard]

Or were you just expecting to always do it on the argument and this is on the option?

[jonsequitur]

I think making ModelBindingCommandHandler public makes more sense than extending the interface but throwing if it's the wrong implementation.

[KathleenDollard]

Closing in favor of non-draft one.