Design default-value help rendering for global options

[autocarl]

Problem

Global option help should eventually be able to show meaningful default values, but the behavior needs a deliberate design rather than being introduced as a side effect of global option descriptions.

PR #34 intentionally focuses on showing global option descriptions in help output. It should not also introduce [default: ...] rendering.

Current considerations

Global option registration already carries some default-value metadata, but rendering it directly in help can be misleading:

• typed global option prototypes can expose implicit CLR defaults such as false or 0;
• nullable and reference-type defaults need different treatment from explicit defaults;
• manually registered options and typed options should behave consistently;
• command option help and global option help should not diverge in semantics.

Desired outcome

Design and implement default-value help rendering for global options intentionally, including support for System.ComponentModel.DefaultValueAttribute.

Things to investigate

• How [DefaultValue(...)] should interact with property initializer defaults on typed global option classes.
• Whether implicit CLR defaults (false, 0, null) should be hidden unless explicitly declared.
• How manually registered global options should declare meaningful defaults.
• How default value formatting should handle culture, enums, nullable types, strings, and booleans.
• Whether command option default rendering should share the same helper/semantics.
• What regression coverage is needed for bool flags, numeric options, strings, nullable values, and explicit [DefaultValue] declarations.

Related

Follow-up from #34 review: remove incidental [default: ...] rendering from the global option description PR and handle default values in a dedicated change.