FR: Support 3 cases for options in API: not given, given without value, given with value

Hi, I'm still using the packaged beta 4 of the library from nuget.org. I noticed that the concepts and API have changed very significantly, but I am in the middle of a large rework, and couldn't find a good time to do it halfway and learn the new changes. Some things that should be easy are really hard in beta 4, but I see that there is a lot of changes to make the API more transparent!

I had a problem specifying a global verbosity option, say `-v`, with the arity `ZeroOrOne`. Naturally, it can be processed only in a middleware, and should; passing it to every command would be ugly. This I implemented easily. However, by my design, I wanted to distinguish 3 cases:

1. The option is not given in command line at all, for no verbosity.
2. The option is specified without an argument, just `-v`. This would default to the lowest level of 1.
3. The option is specified with an argument, e.g. `-v3` to set the level to 3 explicitly.

However, for the life of me, I'm unable to distinguish the cases 1 and 2:
* If I provide a default value factory, the default value is applied and the option is present in the parse result, returned by `ParseResult.FindResultFor(myOption)` has `IsImplicit = true`. `ParseResult.HaveOption(myOption)` also returns `true` in both cases
* If I don't specify the default value factory when construction the option instance, then the option without an argument is silently ignored, so in both cases 1 and 2 `ParseResult.FindResultFor(myOption)` returns `null`, `ParseResult.HaveOption(myOption)` `false`.

I don't know if I'm doing anything wrong, it's well possible. The API looks very complex. I could _possibly_ implement custom parsing, but that's too much already for such a simple use case.

In either case, my FR is to be able to tell apart all 3 cases numbered above. It's a very common pattern with a verbosity or debug switch in Un*x command-line tool. (Another is counting the number of times the switch is repeated, like `-v` for terse debug output, `-vvvv` prolific; but that's very optional).

Thank you for considering this!