Refactor help option implementation to hold actual Option

[shadowspawn]

Pull Request

The main motivation for this refactor is to potentially simplify future work that uses more Option properties. For example, adding help group to Option like in #1910.

Instead of extending .helpOption() to add parallel features like:

program.helpOption('-s, --support', 'Show help', { helpGroup: 'Demo Options:' });

could instead use same approach as normal options:

program.addHelpOption(new Option('-s, --support', 'Show help').group('Demo Options:'));

(This overlaps with motivation and implementation in #1929.)

Problem

Additions to Option that can be used with .addOption() can't be used with the help option. For example, hiding the help option (#689).

There are an annoying number of help option related properties on Command.

Determining the help option flags does not go through cmd.createOption() so misses some potential custom class behaviour, such as custom flags parsing. (Minor!)

Solution

Store a help Option rather than the necessary deconstructed properties.

Add .addHelpOption() to add author created option, exposing more configuration just like .addOption() does.

ChangeLog

• Added: .addHelpOption() as another way of configuring built-in help option
• Changed: refactor internal implementation of built-in help option

[shadowspawn]

Updated with release/12.x changes.

[abetomo]

LGTM

[shadowspawn]

Thanks @abetomo 🚀

[shadowspawn]

I will do another prerelease this weekend with the help command and help option refactor, and then we could perhaps release in a couple of weeks.