feat: include version 2.1 and new bindings

[jonaslagoni]

Description
This PR introduces a few changes to the documents.

1. Bindings have been separated completely from the AsyncAPI spec files, this is because the binding versions are, as I understand completely separate from the spec version.
2. Each binding protocol has been given its own version subfolder i.e. instead of tests/bindings/Message Bindings Object/http/valid.yaml the path given is tests/bindings/Message Bindings Object/http/0.1.0/valid.yaml.
3. I have only added documents for the changes introduces in AsyncAPI 2.1. Not sure how we should handle this moving forward for the upcoming major versions?

Related issue(s)
fixes #80

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[magicmatatjahu]

Please refer to my comments, overall is good :)

However I have problem which should be addressed in the next PR. Why do we use the names of the folder with spaces? I don't think so it's a good, because as I remember we have in plan to publish the tck as separate package to the npm.

The another problem. Why do we have the path's format for bindings: bindings/{OBJECT...}/{BINDING}/{VERSION}? I think that bindings/{BINDING}/{VERSION}/{OBJECT...} will be better.

[jonaslagoni]

However I have problem which should be addressed in the next PR. Why do we use the names of the folder with spaces? I don't think so it's a good, because as I remember we have in plan to publish the tck as separate package to the npm.

Yea I agree, do you mind creating another issue for it?

The another problem. Why do we have the path's format for bindings: bindings/{OBJECT...}/{BINDING}/{VERSION}? I think that bindings/{BINDING}/{VERSION}/{OBJECT...} will be better.

You are right, much cleaner setup, changing 🙂

[magicmatatjahu]

Yea I agree, do you mind creating another issue for it?

#86 :)

[magicmatatjahu]

One change 😄

[magicmatatjahu]

LGTM

[jonaslagoni]

@magicmatatjahu one thing that dawned on me, me saying the bindings do not follow the spec version is bullshit 😆 At least it is once we restructure the operation, message, and channels.

Do you think this is the right approach or should bindings be moved into asyncapi-2.0 ? 🤔

[magicmatatjahu]

@jonaslagoni We have issue for specify spec version in the binding -> asyncapi/spec#590 so I think that binding are "independent" from the spec version. I mean that we should test the binding with asyncapi version separately, so bindings folder is good for me :)