Allow defining hidden args and subcommands

[kbknapp]

Based off an idea in #217

Hidden args and subcommands would not appear in the help messages or suggestions on errror.

They would still appear in usage strings on error.

I'm unsure about allowing them to be seen in groups or not. I'm leaning towards not displaying them in groups....but open to opinions.

[WildCryptoFox]

If a verbose flag is present; expand the help to all.

[kbknapp]

I think that's a good addition. We could even make that an AppSettings variant (UnhideIfVerbose). I think the initial implementation will just have hidden args/subcommands. Then we can add in the unhiding with verbose, because there's also a few oddities about that one which will make it more difficult to implement, but doing so is non-breaking ;)

[WildCryptoFox]

I'm not too sure I know why we have the enum AppSettings? Was this created for parsing purposes only? Don't get me wrong, it makes my macro cleaner because CamelCase is better. :-)

[kbknapp]

I'm not too sure I know why we have the enum AppSettings? Was this created for parsing purposes only? Don't get me wrong, it makes my macro cleaner because CamelCase is better. :-)

The alternative is what we started with, tons of random methods which take a bool value. This somewhat pollutes the public API space, and makes finding "settings" more difficult. Using an enum creates a single place to look for "settings" which apply to an entire application, or subcommand. It also keeps the public API a little more clean (or at least will in 2.x once all the old methods are removed).

Also, I can't find the link but there is a Rust style guide which favors setting(SettingsEnum) over some_setting(bool).

[kbknapp]

The base functionality (i.e. without --verbose unhiding) should be a quick add, therefore I'm throwing this into the 1.4 milestone blocker