Introduction of registries at the top level

Message registries are becoming more and more appealing for teams to leverage as the focus on interoperability and standardised messaging grows. Based on that would I would like to see is the introduction of registries as a top level object so that they can be defined in the 1 location. The difference between a schema path & a registry is that the registry points to the file which contains 1 or more schema definitions/groups whereas schema path refers to a position within the file

The definition of a registry would need to include:
- Url
- Registry Type: enum
- Merge content: enum (none, required, all)

Then the items from the registry can be used via:

```
$ref: '#/registry/{{registryName}}/item/{{path}}
```

If the developer want to switch to a newer version, they just update the registry.

At the same the embed items flag would be useful for importing definitions of objects which are being transported via strings in other objects ie cloud events

No source files, tests, or entry points are identified. Start by reading the current AsyncAPI specification structure and contribution guidance, then determine how top-level registries, registry references, merge behavior, and embedded items should fit together. Done means the proposal has an agreed schema, semantics, examples, and corresponding specification coverage.

Written by the indexing model from the issue text.