Fix canonical YAML options shadowed by deprecated aliases

[gaoxiaomo]

Summary

• decide YAML support using every argparse action registered for a destination;
• keep canonical _StoreAction and _StoreTrueAction options available when a deprecated alias shares the same dest;
• continue rejecting destinations that only have unsupported custom actions;
• add focused coverage for canonical value options, canonical boolean options, and custom-only actions.

Problem

ConfigArgumentMerger currently builds unsupported_actions one action at a
time. A deprecated alias is a custom argparse action and can share its
destination with a supported canonical option. When that happens, the alias
marks the whole destination as unsupported, so a valid YAML option such as
cuda-graph-max-bs-decode: 8 raises Unsupported config option.

Support belongs to the complete action set for a destination, not whichever
custom action happens to be registered last. This change first collects the
destinations backed by a standard store action, then excludes those
destinations from unsupported_actions.

The deprecated CLI alias still parses and emits its warning. The change does
not expose the deprecated alias as a new YAML key.

This addresses the YAML parsing regression reported in #29184. It is a narrow
parser fix and does not implement the broader device-graph naming RFC.

Tests

• focused regression tests: 3/3 passed;
• real ServerArgs check: canonical YAML resolved to 8; deprecated CLI alias
  resolved to 9 and retained its deprecation warning;
• isort, Ruff, Black, codespell, registered-test validation, bare-pytest-main
  validation, py_compile, and git diff --check passed.

---

CI States

Latest PR Test (Base): ❌ Run #32658615064
Latest PR Test (Extra): ❌ Run #32658614941
Latest PR Test (AMD ROCm 7.2): ❌ Run #32658615055