Tuple options don't parse the same as strings

[dwarburt]

Describe the bug
A value for a string option can be specified on the command line with a space separating the option name and value. If it's a tuple, this will cause an "Unrecognized command or argument" instead.

To Reproduce
Steps to reproduce the behavior:

1. Using this version of the library: 2.2.5
2. Run this code:

using System;
using McMaster.Extensions.CommandLineUtils;
namespace tuple_parse
{
    class Program
    {
        static void Main(string[] args)
        {
            CommandLineApplication.Execute<Program>(args);
        }
        [Option("-s|--string <value>")]
        public String StringOpt {get;}

        [Option("-t|--tuple <tuple>")]
        public (bool hasValue, string value) TupleOpt {get;}
        int OnExecute(CommandLineApplication app, IConsole console)
        {
            Console.WriteLine($"string: {StringOpt}, tuple: {TupleOpt.value}");
            return 1;
        }
    }
}

3. With these arguments --string 1 --tuple 2
4. See error: Unrecognized command or argument '2'

Expected behavior
A tuple option should be recognized when the value follows a space.

Screenshots

[natemcmaster]

Tuples map to SingleOrNoValue. In this example, --tuple 2 is ambiguous. This is a limitation of parser, and I haven't found a good solution. What is "2"? The value of --tuple? A subcommand? An argument on the command object? While there may be a set of programs for which we could infer that "2" is the option value, there is a much larger set in which this usage is ambiguous. So, for now you must use --tuple=2 for ValueTuple<bool, string> properties.

FYI this is one of the edge cases I've documented in a doc I started drafting last week. I'll leave this open till this doc is ready.

https://raw.githubusercontent.com/natemcmaster/CommandLineUtils/75de7e3e9d74139f5209d61decde1c78ec6e1237/docs/docs/options-and-args.md