Overview

@JoshuaKGoldberg I went through with my threat for no reason other than it seemed fun.

Previously we usedjson-schema-to-typescript to generate our types, however we have found that the package has a number of edge-cases that don't do what we want. Attempting to change the package is... difficult because it is built to be super flexible so it can attempt to handle every single permutation and valid state of a JSON schema.

However in reality we don't actually need all that power - just a fraction of it because rule schemas are some degree of sane (usually... at least our are). This means we can easily constrain the transformation code and thus simplify it significantly.

This PR:

1. introduces a new (currently internal) package that contains tooling to convert a rule's schema to TypeScript types.
2. introduces snapshot tests for the plugin that snapshots the schema and the generated TS types
   • I realised that running this against our rules is a great way for us to validate our schemas are doing what we think they are - I personally find that seeing the fully resolved schema along side the computed TS types are incredibly helpful in understanding the schemas.
     This has the added benefit that we can validate the types that will get embedded in the website without needing to do a website build - which is a nice, quick sanity check.
3. introduces a test for the plugin that validates that the schemas don't include invalid properties
   • Whilst building the tool I noticed a lot of invalid states in the schema, so I threw together a test to shout about unknown properties. This in turn helped me find a bunch of incorrect schemas!
4. updates the website build to use the new package

Note: I purposely haven't written tests for the tool as it's pretty extensively tested by running on our rules already. I didn't see any need in additional tests.