Migration 005: Order multiple support blocks reverse-chronologically

[queengooborg]

I was looking around for some projects to work on for BCD while my VM hard drive was down (hardware failure a within a month of purchase...urgh), so I found #1596, which discusses ordering arrays of support blocks ("statements") in reverse chronological order, with a few additional rules. This PR aims to introduce a fix script for just that, creating compare-statements.js, and more importantly, fix-statement-order.js. The function orders all statements with the newest first, within the following groups (in order):

1. Statements with only version added and/or removed (and potentially notes)
2. Statements with alternative names or prefixes
3. Statements with partial support
4. Statements with flags

A test has been written as well to ensure the function is behaving as expected. Fixes #1596, fixes #7403.

[foolip]

It looks like this grouping is going to make the support blocks un-chronological in some cases. In particular I'm thinking of APIs that were in Presto or Edge, then prefixed-only in Chromium after the switch, and eventually unprefixed again, like this:

browser-compat-data/api/Element.json

Lines 5870 to 5882 in 3db2dce

	"opera": [
	{
	"version_added": "58"
	},
	{
	"version_added": "15",
	"prefix": "webkit"
	},
	{
	"version_added": "12.1",
	"version_removed": "15"
	}
	],

I think the lint should at minimum allow this order, and ideally require it.

I have some guesses, but it would be good to spell out what the downsides would be of sorting all entries by version unconditionally.

[queengooborg]

This is true, the current code will move that prefix statement down to the bottom. However, I'm unsure on how we can allow for that set of statements while disallowing something like this:

"firefox": [
  {
    "version_added": "61",
    "prefix": "-webkit-",
    "notes": "Added prefixed version for backwards compatibility."
  },
  {
    "version_added": "48"
  }
]

[foolip]

I think we can! First sort chronologically strictly, then find the "best" entry to show by default and move that to the beginning.

Or we move this kind of logic to consumers, making this a much bigger project...

[queengooborg]

I definitely think we should handle the logic here in BCD so that our consumers have less to worry about.

May I pass this PR off to you to implement the logic you recommended?

[queengooborg]

Could we actually hold off on implementing this logic for another PR/migration? While I think this would be great for us to do, I'm just not sure how to put it into code yet, and I'd love to get the order resolved so that our consumers aren't confused by the lack of order...

[caugner]

This is a bit surprising to me that this active support item comes after a chronologicaly older inactive (version_removed) item. 😕

[queengooborg]

The idea was that prefixes would be moved further down in the list, but I see what you mean -- let me update this!

[queengooborg]

I'm self-merging this because the main reviewer for infra PRs is OOO and review comments have been addressed. We can follow up with any sorting changes in the future.