Auto-generated --help option should be a boolean flag, not optionalValue

[stalep]

Summary

When generateHelp = true is set on @CommandDefinition or @GroupCommandDefinition, aesh auto-generates a --help option with optionalValue = true. This causes --help to appear in documentation and help output as if it accepts a value parameter:

-h, --help=_<help>_    Display help (use --help=all for all options)

This is misleading -- --help is universally understood as a boolean flag in CLI tools. Users do not expect --help to take a value.

Current behavior

The auto-generated help option is created in ProcessedCommand.doGenerateHelp() with:

• hasValue = true (to support --help=all)
• optionalValue = true (so bare --help works without a value)

This means:

1. Help output shows --help=_<help>_ instead of just --help
2. Documentation generators render it as a value-taking option
3. Shell completion suggests --help= with a trailing =

Expected behavior

--help should be rendered as a simple boolean flag in help output and documentation:

-h, --help    Display help (use --help=all for all options)

The --help=all variant can still work internally, but the option presentation should not suggest that a value is expected or typical.

Workaround

Documentation generators can special-case --help to suppress the value display, but this shouldn't be necessary.

Context

Found during the jbang picocli-to-aesh migration (jbangdev/jbang#2453). The picocli version rendered --help as a simple flag.

[stalep]

Fixed in commit bcc4f86. Changed the auto-generated --help from OptionType.NORMAL with optionalValue=true and type(String.class) to OptionType.BOOLEAN with type(Boolean.class) and hasValue=false. This makes --help render as a simple flag in help output, shell completion, and documentation generators. The --help=all variant still works because AeshOptionParser.processOption() handles = values on boolean options, and isFullHelpRequested() now scans all values for "all"/"full".