Support AsyncAPI linting using Spectral about megalinter

[nvuillam]

@pjungermann I would prefer the option where OPENAPI_SPECTRAL can handle sync + async APIs ^^

Ypu could rename the default config file as .spectral.yml, and put the mixed config in default content

extends:
  - spectral:asyncapi
  - spectral:oas

Semantically, OPENAPI_SPECTRAL would analyze openapi + asyncapi , but i wouldn't like to create a new descriptor for each new capability

Another solution might be to deprecate OPENAPI descriptor and create a new descriptor API that would contain API_SPECTRAL, but in my opinion that's not mandatory

[nvuillam]

@pjungermann great :)

In order to ensure compatibility until the next major release (usually once a year), please do not remove the openapi descriptor, just add deprecated and create a new api descriptor aside :)

[nvuillam]

@pjungermann would it just work if we update default config file shipped with MegaLinter ?

If not, we could also update the doc to tell to override the config file name using variable OPENAPI_SPECTRAL_CONFIG_FILE

Would you like to make a PR ? :)

[pjungermann]

@nvuillam updating the config file would be a viable option (+ updating docs).

1. reuse same linter and config file
2. separate linter
   1. separate config files (users could override it if they want to use one for both)
   2. shared config file
      1. stick to current file name
      2. use filename as of Spectral's docs

Based on the setup for other linters, I assumed there might be a preference for ASYNCAPI_SPECTRAL.

I'm willing to provide a PR. Before, I wanted to find out the right solution for this project.

[pjungermann]

I like the idea of changing OPENAPI to API as linter grouping 👍

I will have a look at preparing the necessary changes.