ConfigureFromMethod to generate options/arguments from complex types

[davidjenkins]

Proposing that when System.CommandLine.DragonFruit.CommandLine.ConfigureFromMethod() is invoked, and the handler method includes a parameter of a complex type that does not have a string constructor, the public constructor parameters and public properties of the complex type are each interpreted as an option or an argument.

With the proposed change, if a handler such as this...

Action<TaskRequest> handler = (TaskRequest request) => { /* Do what the user asked for. */ };

... where the request parameter is of a complex type such as this...

public class TaskRequest
{
   public TaskRequest(string p1, int p2, Guid? p3 = null, int? p4 = 0)
   {
      // Constructor parameters interpreted as arguments by default.
      // Constructor parameters interpreted as options if default value provided.

      // p1 generates Argument<string>("p1")
      // p2 generates Argument<int>("p2")
      // p3 generates Option<Guid?>("--p3")
      // p4 generates Option<int?>("--p4")
   }

   // Properties interpreted as options.

   public string Foo { get; set; } // generates Option<string>("--foo")

   public int? Bar { get; set; }   // generates Option<int?>("--bar")
}

... then doing this ...

var command = new Command("start");
command.ConfigureFromMethod(handler.Method);

... would achieve the same as this...

var command = new Command("start")
{
   new Argument<string>("p1"),
   new Argument<int>("p2"),
   new Option<Guid?>("--p3"),
   new Option<int?>("--p4"),
   new Option<string>("--foo"),
   new Option<int?>("--bar")
};

... making development and maintenance so much easier, especially for applications with several depths and combinations.

[jonsequitur]

There have been a number of suggestions for making DragonFruit richer using various conventions. @KathleenDollard is working on app models that allow people to define their own. We're hoping that that API allows people to reimplement and extend DragonFruit in ways like this.