Be slightly less aggro about parser ambiguity wrt optional-value flags

[bitprophet]

Spinoff from #33, specifically #33 (comment)

Marking as bug but it's one of those things I'd only want to release in a minor release...esp as it's backwards incompatible. (Soon, so soon, this would be grounds for a major release! but we're still pre 1.0...)

tl;dr try reining in Parser.check_ambiguity() so it doesn't explode when the value given is flag-like, but it would be a valid flag for the current context: it seems more likely that the user was intending to give that 2nd flag (and implicitly NOT giving a value to the optional-value flag being parsed), than that they were intending to give such a flag as a value to this one.

We might also want to remove the check around another possible context/task name, but that one seems more truly ambiguous to me so prob best to leave it.

[bitprophet]

Also, while I am writing up the docs/changelogs for this, I realize - if we are happy resolving that particular ambiguity, it means the other half of it - flag-like values which are not otherwise valid for current context - can also be resolved (and preserved as the optional-value flag's string value.)

[bitprophet]

But also, I now find myself wondering why all of this did not occur to me at the time. Is there something in the parser's design that made the current behavior way more compelling than the "are you valid or not?" test?