Add move and split redirects to the schema

[ddbeck]

Towards #91 and the sequel to #2990.

Because this PR follows #2990, looking at the diff between them might be easier to look at. See: ddbeck/web-features@91-jsonschema-source-of-truth...ddbeck:web-features:91-redirects

This PR does the following:

• Adds redirects to the JSON Schema
• Generates (and embellishes) types for the new schema
• Modifies our scripts to use the new types and support redirects
• Demonstrates both types of redirects, by splitting webcodecs (Split webcodecs into audio-codecs and video-codecs #2918) and moving numeric-seperators to numeric-separators (Fix typo in file name #2484)

This PR mostly follows the mock documentation discussed from #91 (see #91 (comment)). Some changes I made based on the discussion there:

• The reason for changing an ID is moved, instead of renamed, to avoid implying that the ID will change any time the human-readable name field changes.
• The to string/array of strings is now two distinct fields, target and targets, depending on the reason. This is to avoid some weirdness in using a preposition as a noun (i.e., to avoid saying silly things like "this feature has two tos") and to ensure the name of the field implies its type.

[foolip]

I think we should split it, but the fact that this is in caniuse makes me think we should somehow keep webcodecs as well? With composite features or similar we could.

Do we have any other candidates for splitting where the existing entry is just wrong and has no value to preserve?

[ddbeck]

This is a good point. One thing I haven't done is to write guidelines that say when to move or split a feature—I just put these in to demonstrate the fact that one could do it. I think it would actually be best to back out the YAML files from this PR before merging and land those changes separately, especially to make the release notes more informative.

[ddbeck]

Which is to say, once I've written the guidelines, webcodecs might not get a split at all.

[foolip]

Alright, making the actual changes separately sounds good!

We do need to make sure we have a real case for splitting however. If we can only come up with "composite" features that we might later want to merge back together, then I'm not sure we should remove the original feature. Do have features that were combined by mistake and should never be considered one?

[ddbeck]

Hmm, I'm not currently seeing a compulsory split, if we're assuming some future composite feature schema.

It's somewhat easier to find historic cases. #1089 is a case where, without a splitting schema, would produce either a) a breaking release (which is basically what we did, in the pre-1.0 era) or b) a useless composite feature that combines something interoperable and something that never will be. In the latter case, caniuse has a corresponding feature, but I don't think we should follow caniuse's lead there.

There are also cases we've already merged that look a little suspect, where we split something by moving keys, tweaking a description, and just kinda pretending we got it right in the first place (e.g., #2491, #2652). I don't wish to bank on always being on the right side of that line.

Which brings me to my last concern: split ought to be the reverse of merged. If we wish to be able to merge freely, then we'll need a safe undo. Otherwise, merges will have the feeling of a semver-major event for maintainers here, even if it doesn't bump the version number.

[foolip]

Let's use #2776 as the feature to demonstrating split. We'd split that into gradients (2 BCD keys) and conic-gradients (1 BCD key).