Add ranged versions for all of the oldest versions supported by CTs

[queengooborg]

This PR adds ranged versions for all of the oldest versions of browsers supported in BrowserStack and SauceLabs.

[ddbeck]

Sorry, @vinyldarkscratch, but to accept a new ranged version, I need it to be a blocker for some data, not a nice-to-have option. With that in mind, I'm not going to introduce a bunch of version ranges at once. I will only accept version ranges on a case-by-case basis.

When Florian and I first added this to BCD, we chose version ranges as a last resort, rather than allowing any version to have a range. This feels like a move in a direction we intentionally did not want to go.

Also, I have no idea what "CT" stands for.

[queengooborg]

"CT" stands for "Continuous Testing", which is what one calls browser testing services like BrowserStack or SauceLabs. It's not a well-known term, I'll admit. I also realize that I didn't write much of a description for this PR (which is typical of me to do, haha)!

To explain more, this PR was created in succession to #6915 to help get more real values implemented quicker, so that we may reach our goals (both BCD's and my contract's -- of which the latter is 90% to 95% real+ranged API data by the end of the year). Alas, it's quite a challenge to test older browsers, especially ones unavailable through CTs. While I have my own VMs for these older versions, I often have difficulties getting results from them (Safari 1-2 and IE <5 aren't supported by the mdn-bcd-collector project, and often times I have network issues or other situations), and I understand that others may not have the ability to access such VMs.

To help us get to this goal faster, and to allow those who would not be able to test in those older browsers to help get more real data, I wanted to add the ranged values for browser versions not in BrowserStack or SauceLabs. I realize, however, that some of these ranges can probably be removed.

Although these ranges are technically not blockers on data (I can obtain the real versions for these older browsers, though it takes a rather unreasonable amount of time, like in the case of Safari 1-2), I could submit some cherry-picked PRs for individual ranges?

[foolip]

For Chrome, Edge and Firefox, it seems feasible to do the extra work of testing back to their first release and fill in all of the currently missing data, and then never have to worry about very old versions of those browsers again.

For IE, however, it does not seem feasible to determine where support was introduced between IE 1-6, these are the oldest browsers in BCD alongside Opera.

Since it also cannot plausibly matter to web developers whether something was supported before IE 6, a range for IE ≤6 makes a lot of sense to me.

[ddbeck]

OK, since I guess this was a bit controversial, let me elaborate a bit. I'm not categorically opposed to permitting version ranges, but I'm opposed to categorically permitting them.

Here's what I'm looking for to accept a new version range:

• Something intrinsic to the browser's version history that makes a version range significant. So far, all of our existing cases have this, at least in part: Edge because of EdgeHTML→Chromium, Opera because of Presto→Chromium, WebView because of the separate APK, and Safari because of PowerPC.

• A concrete case showing that testing and/or research cannot reasonably resolve a true/null value.

  For the modern browsers, we're pretty lucky: we have a rich bug/source control history available to us in addition to the testing services. It's fussy, but we often have convincing ways to find out what these browsers did in the past. I acknowledge that it's harder to do that with other browsers (especially IE), which is why I'm leaving this escape hatch open.

I'd want to see such cases made for every version range introduced, in keeping with the original, limited introduction of version ranges. I want to make sure that every ranged version is deliberate editorial choice and not turn the the decision-making process over to testing vendors.