feature/payload format boundary

[bascunansalvador]

• Closes Separate JSON-compatible payloads, native Avro payloads, and Avro Projection mode #126
• Closes Support parsed Multi Format Schema objects for Avro payloads #127
• Closes Document payload schema modes and transfer-format boundaries #133

The previous generator flow did not have a clear enough boundary between JSON-compatible AsyncAPI Schema Object payloads and explicit multi-format payload schemas such as native Avro or Protobuf.

That was risky because these are different schema families with different runtime expectations. A payload described as an AsyncAPI Schema Object can be used for Kotlin models, Java models, Spring Kafka DTO APIs, and Avro Projection. A payload declared with schemaFormat, for example native Avro or Protobuf, should not silently flow through those same generators as if it were the same thing.

This PR introduces that boundary explicitly.

Known schemaFormat values are now classified through a typed SchemaFormat model. The parser still accepts known formats, but non-AsyncAPI schema formats are preserved as multi-format schemas instead of being converted into normal AsyncAPI schemas or rejected too early.

GenerationInput now separates regular schemas from multi-format schemas. JSON-compatible AsyncAPI Schema Object payloads continue through the existing model, Spring Kafka, and Avro Projection paths. Native or explicit multi-format component schemas are kept separately so future dedicated generator capabilities can consume them correctly.

Channel analysis now follows the same split. Messages with AsyncAPI Schema Object payloads are analyzed as regular generator messages, while messages with multi-format payloads are preserved as multi-format messages. This prevents native Avro or Protobuf message payloads from being silently dropped or accidentally treated as DTO payloads.

A generator compatibility validation step was added before any files are written. Existing model generation, Spring Kafka generation, and Avro Projection now fail with a clear generator error if they are asked to consume a multi-format payload. This is intentional because these outputs currently support AsyncAPI Schema Object payloads only.

Avro Projection is now documented and enforced as an explicit projection from AsyncAPI Schema Object payloads into .avsc files. It does not consume native Avro schemas and it does not generate Avro SpecificRecord classes. Native Avro and Protobuf generation should be implemented later as dedicated generator capabilities.

The tests were updated to cover the new boundary. Parser tests verify known schema formats, generation input tests verify that multi-format schemas are collected separately, channel analyzer tests verify that multi-format message payloads are preserved separately, compatibility validator tests verify unsupported output combinations, and generator-level contract tests verify that unsupported payload formats fail before output directories are written.

The README and generator strategy documentation were also updated so the public documentation matches the new behavior. But the doc might change later to a more WIKI based approach.