Allow --arg Value for booleans in HfArgumentParser

[sgugger]

What does this PR do?

The primary reason I dived into this PR is because when launching a training with sagemaker, bool arguments need to be passed along with something (e.g. we can't do --do_train, we have to do --do_train True because the arguments are passed as a dict). This is refused by the current argparser.

This PR changes a little bit the way HfArgumentParser handles bool fields in dataclasses. Up until now:

• a bool arg foo with True as a default gives a flag --no_foo that stores False in foo
• a bool arg bar with no default value or False as a default value gives a flag bar that stores True in bar
• an optional bool arg opt gives the same as a bool if its default is True or False. If the default is None, it gives a flag --opt that requires an argument that accepts anything and stores the value as a string (which is obviously a bug)

After this PR, the following happens:

• a bool arg foo with True as a default gives a flag --no_foo that stores False in foo, it also gives a flag --foo that can be used as is (will store True in foo), or by using any truthy/falsy value (--foo yes, --foo True, --foo no...) that will store the result as a proper bool.
• a bool arg bar with no default value or False gives a flag bar that can be used as is (will store True in bar), or by using any truthy/falsy value (--bar yes, --bar True, --bar no...) that will store the result as a proper bool.
• an optional bool arg opt gives the same as a bool if its default is True or False. If the default is None, it gives a flag --opt that requires an argument that accepts a truthy value and stores the value as a proper bool.

In all cases above, when a truthy value is expected but something else is passed (that is not true, false, yes, no, 1, 0, t, f, y, n), an error is raised.

So no breaking changes at all and all bool values can be used with an argument so that sagemaker is happy. Tests are updated and improved to check the behaviors summarized above are all correct.

[LysandreJik]

Cool, LGTM!

[LysandreJik]

Hadn't seen that before, taught me something about types!

>>> class Field:
...     type = Optional[bool]
...
>>> f = Field()
>>> f.type is bool
False
>>> f.type is Optional[bool]
True

[patrickvonplaten]

(nit) would it maybe make more sense to say "Truthy value expected that is either of type bool or one of ['yes', ....]" or else the user always thinks he/she can only pass True or False