Introduce CliAction, make it possible for every Symbol to define one

[adamsitnik]

Overall it was way easier than I expected.

This PR:

1. Replaces ICommandHandler with CliAction
2. Renames Command.SetHandler with Command.SetAction.
3. Changes the exit code approach: every successful program should return 0, so to avoid verbosity command actions provided by Command.SetAction do not need to return an int. In case somebody wants to reuturn an int, they need to implement their own CliAction type (pay for play)
4. Extends Options and Directives with Action property, but not SetAction methods (no need to, as it should be rare to have active options and directives that don't need custom types)
5. It does not expose the new action types, I want to do it in a separate PR, where I am going to write tests for them and move the configuration to these types.

Contributes to #2071

[jonsequitur]

What if two different options having handlers are both present?

[adamsitnik]

We have two possibilities:

• stop on the first active option
• let the last one to be the effective (this is what we already do for commands)

@jonsequitur choosing the last one is the most intuitive way for me. What do you think?

[jonsequitur]

We could also make it a parse error. Of course certain options (like -h) ignore that and the action still runs.

[jonsequitur]

I am not sure whether it should be allowed for Arguments, currently the argument handlers are ignored.

I wasn't expecting this to be available on Argument and I'm not sure how to reason about it. I don't believe I've seen a CLI where I would model something this way.

[adamsitnik]

I wasn't expecting this to be available on Argument and I'm not sure how to reason about it. I don't believe I've seen a CLI where I would model something this way.

That is very true. I've applied following changes:

• Command, Option and Directive expose CliAction Action property
• only Command exposes SetAction methods (for options and directives it's too rare to pollute the public API surface)

[adamsitnik]

We could also make it a parse error. Of course certain options (like -h) ignore that and the action still runs.

Sure, let's discuss it offline with @KathleenDollard. I am going to merge this PR right now to avoid conflict with my next PR (removal of middleware!)

[tmds]

@adamsitnik in #2046 you said: all handlers should return an int.

And here the design is:

Command.SetAction do not need to return an int. In case somebody wants to reuturn an int, they need to implement their own CliAction type (pay for play)

Failures are often expected in command line applications.

Without the capability to return an int, command handler set using SetAction are forced to throw for failure.

This lead to a bad user experience.
And, throwing exceptions for expected failures is a performance anti-pattern.