[GraphQL] Introduce ArgumentParameter for first-class GraphQL schema argument metadata

src/GraphQl/Type/FieldsBuilder.php から始め、getFilterArgs() と getParameterArgs() を比較してから、issue で言及されているメタデータファクトリとリソースエクストラクタを追跡します。GraphQL スキーマに ArgumentParameter ベースのソースと引数構築パスが 1 つあり、影響を受ける PHP 属性、XML、YAML、ドキュメントのパスが更新されていれば完了です。

Context

src/GraphQl/Type/FieldsBuilder.php builds GraphQL arguments from two parallel sources today:

1. Legacy Operation::getFilters() (list of string filter ids) → getFilterArgs().
2. Modern Operation::getParameters() (QueryParameter collection) → getParameterArgs().

Both paths walk FilterInterface::getDescription(), normalize bracketed keys via parse_str, and emit InputObjectType trees — with different output shapes and divergent edge-case handling (see also #7953-adjacent bug around bracketed keys + object-form filters).

Proposal

Introduce an ArgumentParameter (working name) — a metadata-layer concept that marks "this parameter participates in the GraphQL schema" as first-class. FieldsBuilder then has a single source of truth and a single argument-building pass, instead of two divergent paths.

Sketch:

• A dedicated parameter subtype, or an explicit graphQl: true|ArgumentDescriptor flag on QueryParameter.
• Operation::getFilters() is normalized into synthetic ArgumentParameters for GraphQL, deprecating the dual code path inside FieldsBuilder.
• FieldsBuilder only consumes ArgumentParameters.

Scope

• 4.4 / 5.0 — not a backport-friendly change.
• Touches metadata factories, schema builder, probably the resource extractors (PHP attribute / XML / YAML), and docs.

Why a note, not a plan

This issue exists so the idea is tracked. Real design happens later; the 4.3 branch only does the surgical bug fix + helper extraction.