GH-130750: Restore quoting of choices in argparse error messages to match documentation and improve clarity

[savannahostrowski]

In 66b3922 (gh-117766), argparse was changed to use str() instead of repr() when displaying choices in error messages. This was done to improve StrEnum display, but had the side effect of removing quotes from string choices, making error messages less clear and inconsistent with the documentation.

This PR restores quoting and adds special handling for Enum members to display just the quoted value (e.g., 'red' instead of <Color.RED: 'red'>). This also improves clarity for mixed-type choices (e.g., 1, '2' clearly shows int vs string).

• Issue: Wrong output example on invalid options documentation #130750

[sobolevn]

I support explicit quotes, because bar in Python is a variable name, 'bar' is a string. 👍

[savannahostrowski]

@serhiy-storchaka Mind taking a look at this one, since you were involved in the merge of the PR that changed this display?

[serhiy-storchaka]

Looking how is this handled in other programs. On Linux:

$ ls --color=xyz
error: invalid value 'xyz' for '--color[=<color>]'

  [possible values: always, auto, never]

For more information, try '--help'.

On FreeBSD:

$ ls --color=xyz
ls: unsupported --color value 'xyz' (must be always, auto, or never)

Both quote the invalid value, but do not quote the list of valid values.

[savannahostrowski]

There are also plenty of command-line tools that do quote valid choices in error messages, so it's a mixed bag across the ecosystem, I think.

My preference would be to restore the previous quoting behavior here. The PR that changed the display wasn't really about removing quotes; it was about fixing StrEnum, and the loss of quotes was an acknowledged side effect.