feat: source of truth for version support

[dsanders11]

🚧 Kicking this off for discussion.

Currently this information lives in a table in the e/e docs at docs/tutorial/electron-timelines.md, it was copied over directly (with dates tweaked to match expected format).

This PR pulls that data into this repo and exposes a new /support.json and /versions.json (which is just /support.json + /releases.json combined) to act as the single source of truth for this information. There are two generated fields, isSupported (true if the major is not EOL) and isStable (true if the vX.0.0 release exists for the major).

Doing this lets us remove the hardcoding in this repo added in #15 to keep E22 as a stable release, since now that is dynamically determined by the EOL date in src/versions-support.json.

🌎 The big picture idea is this information will be used in a bunch of places in downstream projects:

1. Create a new @electron/versions package which takes the Versions logic from @electron/fiddle-core and refactors to use /versions.json so that supported majors are not hardcoded
2. Update various bots to using the new @electron/versions package and remove the duplicated logic we have with a hardcoded number of supported versions:
   • electron/roller
   • electron/sudowoodo
   • electron/trop
   • electron/unreleased
3. Generate the documentation versions table (the source of this data) on electron/website
   • Currently it does not show v26, because it is showing the docs for v25. If we generate it based on this data, it will be updated each time the website does a deploy (regularly scheduled)
4. Update @electron/fiddle-core and Fiddle to use @electron/versions, ensuring that Fiddle accurately reflects supported majors
5. Use /support.json to pull the stable kickoff date when creating new release project boards on e/e
6. Migrate other repos using @electron/fiddle-core to find the latest stable release to using @electron/versions
   • electron/chromedriver
   • electron/mksnapshot

❓ Soliciting feedback on key names and the overall data shape here. Currently it's an array (similar to the existing /releases.json data shape) but it would also be reasonable to make it an object keyed by the major number, which is what Node.js does with their equivalent at https://github.com/nodejs/Release/blob/main/schedule.json.

Here's what the output for a given major looks like:

$ curl --silent http://localhost:8080/support.json | jq '.[] | select(.major==25)'
{
  "major": 25,
  "alpha": "2023-04-10",
  "beta": "2023-05-02",
  "stable": "2023-05-30",
  "endOfLife": "2023-12-05",
  "isSupported": true,
  "isStable": true
}