feat(Spec): add component:, one key field on every reusable attribute

[DerManoMann]

Overview

Each reusable spec attribute spelled its component key after its own type — schema:, response:, parameter:, header: and so on — and for four of them the same field was also the key the attribute nests under: response: 200 is a status code in an operation and a component name in components.responses, and header, link and example behave the same way. The object cannot tell which it holds, so isRoot() guessed from field presence, RequestBody, Response, Parameter and Link each drew the key-plus-ref line differently, and a response that failed to nest became a component named 200 with nothing said until Cleanup noticed.

One field, component, names the key a reusable attribute is filed under, on every type — including PathItem and MediaType, which had no key at all and could not be reused. The value fields keep their value, the identity has its own field, and the root rule is one rule: keyed means root, and key-plus-ref is either a nested reference or an aliasing component.

The historic spellings keep working through 8.0 and produce the same document — every fixture and example moved to the new spelling with its expected output unchanged — and trigger a deprecation once. Only their use as a component key is deprecated; response: 404 on a nested response or header: 'X-Rate-Limit' on a header inside one is the nesting key and stays. Classic is untouched and reports nothing — the bridge maps its keys to component directly — but the classic → spec migration is now a key rename as well as a change of namespace, so it is no longer the one use line per file the migration path promised.

Changes

• component: on Schema, Response, Parameter, RequestBody, Header, Link, Example, Security\Scheme, PathItem and MediaType
• ComponentName::of() answers with component; ComponentName::normalise() fills it from the historic spellings once per build, before the resolver's first index
• isRoot() follows component on the conditionally-root types; a keyed Header or Example stands alone without Components
• PathItem with a key is a components.pathItems entry and governs no class; 3.0 reports and omits it
• MediaType with a key is a components.mediaTypes entry from 3.2; earlier versions report and omit it
• compilePathItem() emits $ref
• a schema's title is no longer a key fallback; a keyless schema is reported
• the historic spellings marked @deprecated, removed in 8.0, with a runtime deprecation; ROADMAP.md lists them
• Augmenter\Names, Enums, Refs, Inheritance\Schemas and the compiler diagnostics read component
• HybridBridge passes component directly, so classic input never reports
• fixtures and examples on the new spelling; ComponentNameTest and ReusableComponentsTest added
• docs/dev/pipeline.md root taxonomy and the guide's Components section rewritten; reference/spec-attributes.md regenerated
• docs/guide/modes.md migration path names the four classic spellings that become component:, and its v8 line is scoped the way ROADMAP.md scopes it — one use line per file for code already on OpenApi\Spec, plus the component keys coming from classic; the guide's deprecation warning states that classic reports nothing