clarify how to return runtime errors

[lambdafu]

I noticed that main() returns an int, but parse and callback_ return void. On the other hand, there is an exit_code stored in CLI::Error, but CLI11_PARSE catches on the more specific CLI::ParseError. This raises the question how subcommands called through run_callback should return an exit code to main that is not related to parsing, and if this should even be supported by CLI11.
A straightforward approach is to use exceptions. Of course, this can be done without any support by CLI11 already. But given that most of the required code is already in there, it seems reasonable to define CLI::RuntimeError that is handled like CLI::ParseError by CLI11_PARSE, probably by catching on CLI::RuntimeError and making CLI::ParseError derive from that. Then subcommands can simply throw CLI::RuntimeError or derivatives. If this sounds like a good idea to you, I could come up with a pull request for that.

[lambdafu]

It's smarter to keep RuntimeError and ParseError siblings, so that's what I did in #45.

[henryiii]

Two initial thoughts:

• This really makes CLI11_PARSE the recommended/required way to exit. For someone not using CLI11_PARSE, you should be able to do:

try {
    app.parse(argc, argv);
} catch (const CLI::Error &e) {
    return app.exit(e);
}

(I'm okay if CLI::ParseError isn't enough)

• It might make sense to move CLI::Success to a CLI::RuntimeError too. No, I think it works fine as is.

I'll probably push to the PR in a minute.

[lambdafu]

That's ok. I was worried that catching CLI::Error is too grabby, because the other errors are more like programming errors (such as adding options twice), which I thought CLI11_PARSE doesn't catch purposefully. Thanks!

[henryiii]

The other errors cannot be thrown from .parse, though sometimes users wrap too much in the try block. I think leaving CLI11_PARSE as less grabby is a good idea, but direct usage should be at least possible catching CLI::Error.

[henryiii]

I've made RuntimeError a ParseError, since it can only happen at parse time, and will leave the Error catching as ParseError catching. This has the smallest API change.