Identify breaking changes when switching to AsyncAPI

[xibz]

By moving to a modeling language, we are introducing potential breaking changes. For example, the type field in the context, and the reason for that is that the type field in many languages, like java, utilizes the type field for polymorphism.

In this file, we start from spec 0.4 but try to be more like the documentation spec
and to translate it into doc & sdk with some changes:

• one type per subject
• one type per predicate
• remove of the subject.content, replace by subject.predicate
• the list of predicates per subject
• examples follow the format of https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-00#rfc.section.9.5 (that is different from openapi's operation)
• x-stage is used to indicate the stage of the subject (and the predicates):
  core, source-code-version-control, continuous-integration, testing,
  continuous-deployment, continuous-operations
• rename type to kind because type is a reserved word in lot of languages?
  (on an other side if type is used only as discriminator (too tag enum)
  maybe it could be removed from the generated structures)
• for name of subject'subtype, only the first letter is capitalized (not a PascalCase)
• for name of predicate, concatenate the subject'subtype and the predicate'subtype with predicate subtype capitalized, then
  • predicate & subject could extracted without ambiguity (to snake_case + split on '_')
  • no conflict between predicate that could have the same name (eg. started, finished) but different subject'subtype
• rename url to uri (to be consistent in every place and with the type'name)
• $id should be the same as the type name (like title in openapi, buy it is not used here)

https://github.com/davidB/sandbox_cdevents_spec/blob/main/asyncapi/spec/v6/cdevent.yaml

[xibz]

Generate for Go and Java | Rust | any OO language

The reason for this is Go doesn't have OO concepts, which can have oddities when we model OO in the modeling language. It is completely up to the generator on how that is handled, which may be handled well or poorly.