Remove `CommandLineConfigurationException`

[jonsequitur]

    // Is this something people actually need to catch?  If not, consider not making it public.
    // And if they do need to catch it, is it actually different enough from any existing exception to warrant a new type?
    public class CommandLineConfigurationException : Exception, System.Runtime.Serialization.ISerializable 

[adamsitnik]

I am not sure which exception we should use instead:

• ValidationException has the right name, but it does not support .NET Standard 2.0 and it might end up creating unnecessary dependency
• dictionary throws ArgumentException when a duplicate is being added, but here the exception does not refer to the argument provided to the method, rather to the state of the validate object

[KalleOlaviNiemitalo]

CommandLineConfigurationException is thrown for two possible errors:

• cycle in command hierarchy

  command-line-api/src/System.CommandLine/CommandLineConfiguration.cs

  Line 129 in e965ae2

  throw new CommandLineConfigurationException($"Cycle detected in command tree. Command '{command.Name}' is its own ancestor.");

• duplicate alias

  command-line-api/src/System.CommandLine/CommandLineConfiguration.cs

  Line 145 in e965ae2

  throw new CommandLineConfigurationException($"Duplicate alias '{symbol2Alias}' found on command '{command.Name}'.");

Some candidates from .NET Standard 2.0:

• AmbiguousMatchException: no, not appropriate for validation before there are binding criteria.
• DuplicateNameException: no, documented as DataSet-specific.
• FormatException: no, the problem is not in an argument nor in a format string.
• InvalidConstraintException: no, the constraint is correct, the data just doesn't comply with it.
• InvalidDataException: no, the data is not in a stream.
• InvalidOperationException: "a method call is invalid for the object's current state", that seems pretty close.
• ProtocolViolationException: no, not a network protocol.
• SyntaxErrorException: no, that's for expression strings, not for multi-object structures.
• VerificationException: no, that's for type safety in Code Access Security.
• WarningException: no, this should be an error rather than a warning.

InvalidOperationException seems best.

[jonsequitur]

I think that we went down this same path before giving up and deciding to use a custom exception type. InvalidOperationException feels a little wrong here because it would imply that the CommandLineConfiguration instance is not in the correct state to be validated.

[KalleOlaviNiemitalo]

Did Stream.ObjectInvariant() ever throw anything?

[KalleOlaviNiemitalo]

InvalidOperationException feels a little wrong here because it would imply that the CommandLineConfiguration instance is not in the correct state to be validated.

If the method were instead called RequireValid then InvalidOperationException would feel less wrong.

Another option is to return the error instead of throwing it. Unfortunately ValidationResult is not in .NET Standard 2.0 either.

Is something like public string Validate() used anywhere else? Windows Forms has ErrorProvider with string GetError(Control) but that just retrieves a previously stored error string instead of validating any data during the call.