feature/avro specific records

[bascunansalvador]

Closes #128

Related to #131, #134, #139

The previous generator setup could preserve native Avro schemaFormat payloads, but it did not have a complete generation path for using those payloads as type-safe JVM artifacts. Native Avro schemas were still separate from the regular AsyncAPI Schema Object path, and Spring Kafka client generation could not yet use generated Avro payload types in producer, consumer, listener, or handler APIs.

This was limiting because Avro is not just another JSON-compatible schema projection. Native Avro contracts should be consumed as Avro schemas, written as .avsc artifacts, and optionally compiled into Apache Avro Java SpecificRecord classes. For Spring Kafka APIs, those generated Avro classes are the type-safe payload surface we want to reference.

For the proposed solution, native Avro generation now writes .avsc schema artifacts from Avro schemaFormat payloads. It can also generate Apache Avro Java SpecificRecord source files by using Avro’s compiler. These Java sources are treated as their own generated artifact kind, so they can be routed to a Java source output directory instead of being mixed into Kotlin source output or resource output.

The generator configuration was extended across core, CLI, Maven, and Gradle so users can explicitly enable native Avro generation and choose whether SpecificRecord sources should be generated. By default, native Avro generation creates SpecificRecord sources when the native Avro capability is enabled.

Spring Kafka client generation now supports native Avro message payloads. When a message payload uses a native Avro schema, the generated Spring Kafka producer, consumer, listener, and handler APIs reference the Java type declared by the Avro schema namespace and name. For example, an Avro schema with namespace: com.example.avro and name: UserCreated is used as com.example.avro.UserCreated.

The bundler was also adjusted so multi-format schema references can be bundled without being cast into regular AsyncAPI Schema Object models. This keeps native Avro schema references intact and avoids coupling native schema formats to the JSON-compatible model path.

Several error paths were tightened as well. Invalid native Avro schemas now fail with a domain-specific generator error. Native Avro schemas that cannot produce a named JVM client type, such as primitive Avro schemas, are rejected with a clear message explaining that generated client APIs require a named Avro record, enum, or fixed schema.

Approval coverage was added for native Avro output. The approved files now cover both the generated .avsc artifact and the generated Apache Avro SpecificRecord Java source, giving us a stable baseline for the actual generated output.

The README was updated to document the current native Avro behavior, including Maven, Gradle, and CLI configuration examples. It also clarifies the boundary between Avro Projection and native Avro generation, and explains that Spring Kafka can reference native Avro payload types while runtime serializer/deserializer wiring is still handled by the consuming application.

Tests were added and updated for native Avro generation, SpecificRecord generation, output routing, approval baselines, configuration frontend behavior, Spring Kafka native Avro payload typing, compatibility validation, and bundling of multi-format schema references.