Move `Parse` extension methods to the appropriate `Symbol` types

[jonsequitur]

        // This method group looks fine, but should be an instance method on Argument, or a non-extension method somewhere else.
        // I recommend using different names for the two overloads.  That would allow you to use `params string[] args` for the latter.
        // Argument::Parse(string) and Argument::ParseArguments(params string[] args), maybe?
        public static ParseResult Parse(this Argument argument, string commandLine);
        public static ParseResult Parse(this Argument argument, string[] args);
    }

[KalleOlaviNiemitalo]

Call it ParseArgumentList so it is similar to ProcessStartInfo.ArgumentList.

[jonsequitur]

One possible concern there is that "argument" means something more specific in the context of the parser.

[KalleOlaviNiemitalo]

params string[] args doesn't seem that useful here, anyway. Callers would usually have the args in a collection object already, except perhaps in tests where you can just do new[] { "…", … }.

[jonsequitur]

params string[] args doesn't seem that useful here, anyway. Callers would usually have the args in a collection object already, except perhaps in tests where you can just do new[] { "…", … }.

And we've been trying to discourage testing that way because it requires you to know how the command line input string will be split into an array of strings, which is not at all straightforward: #1758.

[KalleOlaviNiemitalo]

It's well understood for POSIX sh.

[adamsitnik]

fixed in #1951