Enums are not case insensitive

First off: great job, guys!

Small issue: it looks like even though the wiki states that option properties bound to enum values are case insensitive:

When specifying enum values, you don’t need to respect case. Both app -g bye and app --greet-type REGARDS are allowed.

unfortunately, they are not. I have a program that for a line like this:

settings -s gogo -v 23 -t int

where -t is bound to an enum SettingType {Int, String, ...}, I get an error:

ERROR(S):
  Option 't, type' is defined with a bad format.

  -s, --setting      The name of a setting to be added or modified.

  -v, --value        The new value of the setting. The option is required if -s or --setting is specified.

  -t, --type         (Default: String) The case-sensitive type of the value of the setting. The option is not mandatory and if not specified, the
                     type will be either implied from the existing setting with the same name or it will be assumed to be 'String'. The most common
                     types are: String, Int, Guid, Decimal, Boolean, DateTime, Date, Time, Uri, TimeSpan. DateTime values are assumed to be UTC.

[...etc]

BadFormatConversionError
  StopsProcessing          = False
  Tag                      = ErrorType.BadFormatConversionError
  NameInfo                 = NameInfo
    LongName                 = type
    NameText                 = t, type
    ShortName                = t

But if I enter the command like this:

settings -s gogo -v 23 -t Int

all is good.

[giuliov]

It would be nice if you merge this PR after so many months.

[harlam357]

Also experiencing the same issue using the latest v2.2.0 package. Setting CaseInsensitiveEnumValues = true has no effect.