feat(rulesets): add AsyncAPI v3 support (#2697)

* feat(rulesets): add asyncapi v3 support

* chore(rulesets): remove unused file

* chore(rulesets): remove unused file

* chore(rulesets): update dependencies

* chore(rulesets): update dependencies

* chore(rulesets): update test harness

---------

Co-authored-by: Nauman <[email protected]>

docs/getting-started/1-concepts.md

@@ -8,7 +8,7 @@ To achieve this, Spectral has three key concepts:
 - **Functions** accept a value and return issues if the value is incorrect.
 - **Rulesets** act as a container for rules and functions.
 
-Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md), [AsyncAPI v2](./5-asyncapi.md), and [Arazzo v1](./6-arazzo.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI/Arazzo documents are valid.
+Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md), [AsyncAPI v2 and v3](./5-asyncapi.md), and [Arazzo v1](./6-arazzo.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI/Arazzo documents are valid.
 
 By far the most popular use-case of Spectral is automating [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github&utm_medium=spectral&utm_campaign=docs), implementing rules that your Architecture, DevOps, API Governance, "Center for Enablement", or "Center of Excellence" teams have decided upon. Companies generally write these style guides as wiki pages, and several can be found on [API Stylebook](http://apistylebook.com/), but most of these rules could be automated with Spectral. For example:
 

docs/getting-started/3-rulesets.md

@@ -13,7 +13,7 @@ The fastest way to create a ruleset is to use the `extends` property to leverage
 Spectral comes with three built-in rulesets:
 
 - `spectral:oas` - [OpenAPI v2/v3 rules](./4-openapi.md)
-- `spectral:asyncapi` - [AsyncAPI v2 rules](./5-asyncapi.md)
+- `spectral:asyncapi` - [AsyncAPI v2/v3 rules](./5-asyncapi.md)
 - `spectral:arazzo` - [Arazzo v1 rules](./6-arazzo.md)
 
 To create a ruleset that extends both rulesets, open your terminal and run:
@@ -22,7 +22,7 @@ To create a ruleset that extends both rulesets, open your terminal and run:
 echo 'extends: ["spectral:oas", "spectral:asyncapi", "spectral:arazzo"]' > .spectral.yaml
 ```
 
-The newly created ruleset file can then be used to lint any OpenAPI v2/v3 or AsyncAPI descriptions using the `spectral lint` command:
+The newly created ruleset file can then be used to lint any OpenAPI v2/v3 or AsyncAPI v2/v3 descriptions using the `spectral lint` command:
 
 ```bash
 spectral lint myapifile.yaml

docs/getting-started/5-asyncapi.md

@@ -1,6 +1,6 @@
 # AsyncAPI Support
 
-Spectral has a built-in [AsyncAPI v2](https://www.asyncapi.com/docs/specifications/v2.0.0) ruleset that you can use to validate your AsyncAPI files.
+Spectral has a built-in AsyncAPI [v2](https://www.asyncapi.com/docs/specifications/v2.0.0) and [v3](https://www.asyncapi.com/docs/reference/specification/v3.0.0) ruleset that you can use to validate your AsyncAPI files.
 
 Add `extends: "spectral:asyncapi"` to your ruleset file to apply rules for AsyncAPI v2.
 

docs/guides/4-custom-rulesets.md

@@ -31,6 +31,8 @@ Formats are an optional way to specify which API description formats a rule, or
 - `aas2_4` (AsyncAPI v2.4.0)
 - `aas2_5` (AsyncAPI v2.5.0)
 - `aas2_6` (AsyncAPI v2.6.0)
+- `aas3` (AsyncAPI v3.x)
+- `aas3_0` (AsyncAPI v3.0.0)
 - `oas2` (OpenAPI v2.0)
 - `oas3` (OpenAPI v3.x)
 - `oas3_0` (OpenAPI v3.0.x)