Add custom helptext when --json is used

[untitaker]

Fix #89

This doesn't actually implement any features (such as, selecting
specific JSON fields). All it does is steer the user to the right
option. The only reason I wanted this flag to begin with is so that
alias gh=forge becomes a better experience.

[andrew]

--json with no value won't reach this path — cobra's StringVar errors with "flag needs an argument" before RunE runs. So forge pr view 1 --json gives the generic cobra error, and only forge pr view 1 --json title gets the helpful message. gh pr view --json (bare, to list fields) is a common invocation, so worth catching: set cmd.Flags().Lookup("json").NoOptDefVal = " " (or similar) so the bare form also lands in your Changed("json") check.

Also: this and #109 both edit the top of prViewCmd's RunE — whichever lands second will need a small rebase.

[untitaker]

--json with no value won't reach this path

I didn't know optional values for options were a thing because of parsing ambiguity. and indeed now forge pr view 1 --json title parses title as a positional argument. --json=title does give the helpful message. i guess that's still an improvement.

but with #109 (i.e. optional pos arg) i don't know how to feel about this:

forge pr view --json 1

is 1 a PR ID or a json field? both are optional, and the only way to distinguish them is to check whether it's numeric, which is logic i don't think can be integrated into cobra

[andrew]

Thanks — the NoOptDefVal wiring at internal/cli/pr.go:113 is the right hook, and your note about optional-value parsing tradeoffs is fair.

Blocker

Args: cobra.ExactArgs(1) runs before RunE, so the most natural "what fields are available?" invocation — forge pr view --json with no positional — still gets cobra's generic accepts 1 arg(s), received 0 instead of the new hint. That's the exact case NoOptDefVal was meant to cover, so the fix is incomplete.

Switching to cobra.MaximumNArgs(1) and moving the missing-PR-number check inside RunE (after the --json short-circuit) closes it. Worth coordinating with #109, which is loosening the same Args for its own reason.

Tests should follow: TestPRViewJSONFlagNotSupported cases all pass "1" and use --json=field. Add {"pr", "view", "--json", "1"} to pin the bare-flag form, and once the arg-count is fixed, {"pr", "view", "--json"} to pin the no-positional path.

Nits (not blocking)

• NoOptDefVal = " " (a single space) is cryptic — a one-line comment along the lines of "any non-empty sentinel — value unused, we only check Changed" would help the next reader.
• strings.Contains(flagJSON, "comments") will also match hypothetical fields like totalComments. No such field today; fine.
• MarkHidden("json") is the right call for a not-supported flag.
• Rebase with #109 noted last round still pending; whichever lands second resolves it.