Feature: Plan for versioned documentation

[etrepum]

Currently, all documentation is generated whenever main is deployed. This can be confusing for users when there are new APIs or deprecations such that the documentation does not match the behavior or features of the latest released version.

A short-term plan might be to simply mark the documentation website (and playground) with some information that lets users know that the documentation reflects main and may not be available in a released version. Docusaurus does this with a note:

This is unreleased documentation for Docusaurus Canary 🚧 version.
For up-to-date documentation, see the latest version (3.3.2).

Longer term, whenever the API is considered stable, it would make sense to have multiple doc website available (e.g. 19.react.dev, 18.react.dev) or to use docusaurus versioning. Some possibilities for interim middle-ground solutions:

• Start marking methods/features with a @since tag, although that wouldn't necessarily cover deprecations where the example code changes to match main in a backwards incompatible way (as in Update react.md #6141 or Bug: Destructuring LexicalErrorBoundary in React Import Causes Typescript Error #6158)
• Always deploy two doc websites, one for main (maybe call this next or canary) and one that reflects the latest released version.

[etrepum]

Current consensus is that we should have two doc sites, we didn't go into detail about using @since tags, I don't think that's as important at this 0.x stage.

Logistically the following things should happen:

• Decide on a name for the doc site (e.g. next.lexical.dev or canary.lexical.dev)
• Add the code to display the version the doc site corresponds to (even just next or latest), could even be done client-side based on the URL, so that people know they are looking at docs that may include unreleased features
• Change the release workflow to maintain a release branch (latest? release?) that tracks the most recent manually published version (like the latest tag in npm) (see also Feature: Automated nightly releases #6169)
• Provision DNS and web hosting (Vercel?) for this new doc site deployed from that branch

[etrepum]

Now that #6204 is released, we have the necessary build infrastructure to manage multiple documentation websites, but any further progress on that is blocked on other people with elevated privileges doing things:

1. Another release on the latest channel needs to happen to create the latest__release branch (v0.16.0 was released before [*] Feature: Automated nightly releases #6204)
2. Someone at Meta needs to change the Vercel config for lexical.dev to build from the latest__release branch
3. (optional) Someone at Meta needs to set up a new Vercel site (and probably add Cloudflare DNS) for the domain that tracks a more current build (e.g. next.lexical.dev, nightly.lexical.dev, canary.lexical.dev, etc.) from an appropriate branch (e.g. main or nightly__release)

Based on whatever course of action happens for 2 & 3, we can easily add the appropriate identifying information to the website (basically just making it clear what version you're looking at, maybe by putting the version number in the header like react.dev, possibly some other sort of warning if it's tracking main or nightly)