Fix some help and GetRequiredValue issues

[jonsequitur]

This fixes the following issues:

• Option/Argument.GetRequiredValue throws when DefaultValueFactory is set and help is requested #2592
• When displaying default values do not display [] when value is null #2582
• GetRequiredValue throws for implicit values #2573

The approach I took to fix #2573 makes Argument<bool> and Option<bool> have an implicit DefaultValueFactory. This change drove changes to the HelpBuilder so I also fixed #2582 while I was in there.

It's not obvious to me that this is the right fix, so I thought that the PR would help clarify the discussion.

For example, should other types than bool have this behavior of an implicit default value?

[adamsitnik]

LGTM, thank you for fixing all the issues @jonsequitur !

[adamsitnik]

nit: we can define a static lambda to reuse it for all other boolean arguments

Suggested change

	boolArgument.DefaultValueFactory = _ => false;
	boolArgument.DefaultValueFactory = static _ => false;

[adamsitnik]

subjective nit: I am not convinced that switch is the best construct in this case, as it's unlikely that we need other types with such special handling (if should be just fine).

It would be also nice to add a comment explaining why it's needed.

[jonsequitur]

Agreed, if is cleaner. I was considering whether other types should have similar treatment.

[adamsitnik]

nit: since all the callers use Argument.None, could it be made private?

Suggested change

	internal class NoArgument : Argument
	private sealed class NoArgument : Argument

[adamsitnik]

just for my education: why do we need it here?

[jonsequitur]

This changes the behavior of the assertions so that all will be evaluated and reported even if the first one fails. Multiple assertions in a test is often considered an antipattern because they can fail independently and failing the test on the first assertion failure loses useful information.

The AssertionScope approach provides a way to make sure all assertion results are reported.

[adamsitnik]

This changes the behavior of the assertions so that all will be evaluated and reported even if the first one fails. Multiple assertions in a test is often considered an antipattern because they can fail independently and failing the test on the first assertion failure loses useful information.

The AssertionScope approach provides a way to make sure all assertion results are reported.

Thanks a lot! It would be great if we could enable it project-wide without a code change (like a csproj setting)

[jonsequitur]

That could be done using a base class (to instantiate this in the constructor and dispose it in Dispose) but I find in well designed tests, multiple assertions aren't the norm and I prefer not to encourage this. One scenario per test should usually guide tests toward one assertion per test.