Changes

Introducing Astro features. Astro features are features that astro has out the box, and sometimes users can opt-in.
Few examples:

• staticOutput if a user uses a specific adapter, the adapter needs to be able to serve those static assets. An example is Cloudflare, which doesn't support it.
• assets: not supported by those adapters that are incompatible with node

This PR adds a new API that adapters can use when registering one. It's called supportedFeatures, and it's a new way to tell Astro if and when an adapter is able to support certain features that are enabled via configuration.

The adapter can also tell Astro the kind of support:

• stable
• experimental
• unsupported
• deprecated

For now, this new API/object is not mandatory, but it will be in Astro 4.0.

The PR also updates the adapters that we maintain, and it adds the feature map to them.

About assets

There's a small caveat for the assets. Astro assets is a feature that is already turned on by default, meaning that Astro sets already a default service. This means that adapters that don't support assets will always get an error, which is inconvenient. I came up with a solution where we set the default after the adapter validation, although I don't like the solution very much, and I wonder if there's a better way to handle a case like this.

The assets feature is just an example; we might have the same problem with future features like this. What do you suggest?

Testing

I added new unit test cases and updated the existing ones.

Docs

I will create the changelog in another PR