Replace raw stdlib parse errors in typed flag Set methods (#269)

[reuvenharrison]

Refs #269.

Problem

Each typed flag's Set method returns the strconv (or time.ParseDuration) error verbatim, so users see internal-looking text:

$ mytool --some-flag=x
Error: invalid argument "x" for "--some-flag" flag: strconv.ParseBool: parsing "x": invalid syntax

The leading invalid argument "x" for "--some-flag" flag: shape is fine — it tells the user what failed and where. The trailing strconv.ParseBool: parsing "x": invalid syntax is implementation detail leaking to end users.

Same shape applies to int* (strconv.ParseInt), uint* (strconv.ParseUint), float* (strconv.ParseFloat), and duration (time.ParseDuration).

Change

Each typed flag's Set method now returns a human-readable hint when the underlying parse fails:

Flag type	Suffix
bool	must be true or false
int, int8/16/32/64	must be an integer
uint, uint8/16/32/64	must be a non-negative integer
float32/64	must be a number
duration	must be a duration like "30s" or "5m"

Result:

$ mytool --some-flag=x
Error: invalid argument "x" for "--some-flag" flag: must be true or false

The outer invalid argument %q for %q flag: %v shape from InvalidValueError.Error() is unchanged; only the cause changes.

Scope

• 14 typed-flag files, one Set method each, identical pattern.
• flag_test.go updated: the existing assertion in testParse (line 398, the --bool=abcdefg case) now asserts the new message.
• New TestInvalidArgumentMessages table-driven test locks in the suffix per type so future drift is caught.
• Slices, arrays, and map types are out of scope for this PR. They have a different shape (per-element parsing inside loops) and would be a natural follow-up if the approach lands.

Backwards compatibility

The error type returned from Parse is still *InvalidValueError. Code using errors.As(err, &ive) continues to work. The cause chain (errors.Unwrap to reach the *strconv.NumError) is no longer present, since the new errors are plain errors.New. Any caller that drilled into the wrapped strconv error would need to switch to inspecting InvalidValueError.GetFlag().Value.Type() instead. I expect such callers to be vanishingly rare; happy to add an errors.Is sentinel if maintainers want a stable handle.

[CLAassistant]

All committers have signed the CLA.

[tomasaschan]

Thanks!

I'm on the fence on whether it's worth introducing stable errors for the different cases (at least a few strings passed to errors.New are repeated here), and then also whether to export them. The stdlib flag package seems to introduce them unexported, which from a user's perspective isn't that different from the repeated approach here (you can't use Is on them anyway), so I think we can merge this as is and then iterate if anyone asks for stable errors to reference.