[v2] Website deploy plan

[LeaVerou]

Architecture outlined here. This is about the website part of this.

• Roll back the separate plugins repo (so sorry @DmitrySharabin for leading you down the wrong path 😢). We still have the plugins in the prism repo, so presumably all we need to do is move their docs back here (under /plugins/).
• Build script that reads plugin/language/theme metadata from prism and prism-themes
• v1.prismjs.com points to the current website
• v2.prismjs.com points to the website for v2 which will be deployed from the website's v2 branch
• prismjs.com is aliased to v1.prismjs.com
• Once we have a pre-release of v2, we update v1.prismjs.com to link to it
• Once v2 is in a more mature beta, we switch prismjs.com to v2.prismjs.com and have a link to the v1 version.
• Nice to have: Remove the minified assets from the v1 website, generate them with a build script which will also store filesizes (of both the minified and non-minified components) in a JSON file

There are several things to do to the website itself, but these are for later.

[DmitrySharabin]

The current website is served from this repo (the v1 branch), and now all corresponding files can be safely removed from the Prism master branch. I can do that as soon as we agree.

Plugins docs (for Prism v1) also live here (on the same v1 branch), so we can remove their HTML files from the main repo. I can combine this step with the one where we remove minified assets from the main repo and generate them during the build step.

[LeaVerou]

Sorry, I did not explain it well :(
Plugin docs (README files) should live with the plugins. In general, plugins should be as self-contained as possible. One should be able to send a single PR to add a plugin, they should not have to PR multiple repos. The website should read those README files and generate HTML files.

[DmitrySharabin]

Extract from #42 (so as not to miss the things out).

By @LeaVerou

For plugins, we already have their readmes that should contain all their metadata as 11ty data. For languages, that would be too heavyweight, so we could follow a mixed approach: Declare their metadata at the top of the file using a doc comment (that is then picked up by our build process), and have MD files for those that want to declare more details. Then, our build tool produces MD files for the rest. These pages should also host the examples for each language, which are currently a separate app with questionable UX where you select the languages you want to see examples of via checkboxes (which seems clever, but is not how anyone looks for examples of certain languages, so it just becomes a hassle)