Add macroAnnotations config option to attach attributes to generated types

[mackoj]

Motivation

There's no way to put an attribute or macro on a generated type today. The generated files get overwritten on every run, so the only options are post-processing them or forking the generator.

Requested in #383, and discussed on the forums, where adding this was welcomed: https://forums.swift.org/t/customization-and-namespacing-for-swift-openapi-generator-generated-code/81856/4

Addresses #383.

Modifications

• New macroAnnotations config key:
  • schemas: attributes per component schema name. * matches every schema; its attributes come first.
  • client: attributes for the generated Client struct.
• New Declaration.annotated case, rendered as one attribute per line before the declaration, after any doc comment.
• Handle the new case in recursion detection, boxing, and the access modifier accessors.
• Document the key in "Configuring the generator".

Attributes are emitted as-is, without validation. Modules they need go in additionalImports.

additionalImports:
  - MyMacros
macroAnnotations:
  schemas:
    "*":
      - "@MyMacro"
    Pet:
      - "@MyOtherMacro(option: true)"
  client:
    - "@MyClientMacro"

Result

/// - Remark: Generated from `#/components/schemas/Pet`.
@MyMacro
@MyOtherMacro(option: true)
public struct Pet: Codable, Hashable, Sendable { ... }

Client gets @MyClientMacro. Without macroAnnotations, output is unchanged.

Server and generated methods aren't covered yet; I can add them in a follow-up.

Test Plan

• Test_TextBasedRenderer.testAnnotated: rendering, including with a doc comment.
• Test_Config: wildcard and per-schema resolution, attribute placement.
• SnippetBasedReferenceTests.testMacroAnnotationsSchemas and testMacroAnnotationsClient: end-to-end translation for schemas (struct and enum) and Client.
• swift test and swift format lint --strict pass locally.

[czechboy0]

Hi @mackoj,

thanks for getting started on this, but these days we require an issue to be assigned to you before you can open a PR. That's mainly to save you time, ensuring we have alignment before you spend too much time working on the code.

This is definitely a large enough feature that it'll require a proposal (see our docs).

But for now - can we move the discussion to the issue, and dig into what your preferred approach is? One thing I'll say right away - the feature must work both for client and server generation, we wouldn't accept this only for one of them.