gh project item-edit/item-list: address fields, options, and items by name #13816

Describe the feature or problem you’d like to solve

gh project item-edit and item-list currently require ProjectV2 node IDs for the project, item, field, and single-select option. Getting those IDs means extra field-list/item-list preflight calls and copy-pasting opaque IDs, which is especially painful for scripting and for agents driving gh. Every other gh project verb that touches items (e.g. item-add) already accepts a human-readable [<number>] --owner --url addressing scheme, so item-edit is the odd one out.

Proposed solution

Add additive, backward-compatible name-based addressing that mirrors item-add:

gh project item-edit <number> --owner monalisa \
  --url https://github.com/monalisa/myproj/issues/23 \
  --field "Status" --value "In Progress"

gh project item-list <number> --owner monalisa --field "Status"

• Existing --id/--field-id/--project-id flags are untouched; name flags are opt-in.
• --value is dispatched by the field's data type; for single-select it resolves the option name.
• Name matching is case-insensitive, mirroring the Projects v2 platform API.
• Resolution happens before the mutation, so bad names fail loudly with candidate lists instead of 400 [].

Benefits CLI users (no more ID spelunking for a one-line edit) and unblocks agent/automation workflows that address Projects by name.

Additional context

• A working implementation already exists as a draft PR: Add name-based resolution to gh project item-edit #13807 (name resolvers + both command surfaces, ~two-thirds tests).
• Part of a broader effort to bring Projects automation to parity across gh and the GitHub MCP server; a sibling MCP change (MCP: name-based resolution for Projects fields github/github-mcp-server#2760) adds the equivalent resolution there, and the two are being kept semantically aligned.
• Internal tracking issue: github/planning-tracking#3431.