feat: refine container APIs for renderers

[ematipico]

Changes

This PR consolidates the API introduced in #11234

Closes #11181

I changed the signature the API to accept an object. The object can accept a renderer (new renderer) and renderer + name for renderers.

Why add name to renderers and making it mandatory? The name comes from the AstroRenderer interface, which is the interface meant to tell Astro how to load the renderer itself. Once the renderer is loaded, Astro adds the name to the resolved renderer. However, with this API, the user must import the renderer itself, and they provide the name themselves. Although the name isn't arbitrary; internally, we have a few exceptions/checks around the name, e.g. @astrojs/lit.

In this PR, I updated the exported server.js files to export the name too, and I added a small interface to make them easily discoverable via TS.

Testing

Updated an existing test

Docs

I updated an existing changeset because we haven't released the former API yet

[changeset-bot]

⚠️ No Changeset found

Latest commit: b98ba47

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[matthewp]

I think the fact that renderers have a name is a remnant from before the days we had integrations. So you'd add a renderer directly, and it got a name mostly for debugging purposes.

[ematipico]

Myself and Matt checked that, and unfortunately there are few instances where the name is used for business logics:

• find the mdx/jsx astro renderer
• exclude the lit client renderer from doing some stuff