Better define the backwards compatibility/API policy for JavaScript

Added some related issues around bumping the airbnb version that we lint against.

The jQuery 3 upgrade in Drupal 8.4 was mentioned in the release notes, but it was easy to miss. It's certainly a roadblock for sites to upgrade to Drupal 8.4, which is concerning given that 8.3 no longer has security support. Whatever policy there is should cover both external dependencies and Drupal specific code.

For our clients, it certainly would have been more straightforward to have a Drupal 9 release that was nothing but Drupal 8.3 + the Symfony and jQuery upgrades.

Thanks @deviantintegral. I was extremely reluctant to allow major version updates of dependencies in minor releases, but I was in the minority among the committers for that. It did become clear that there is also a lot of risk in not updating the libraries. (For Symfony, we announced before 8.0.0 was even released that we would upgrade to ~3.x during the 8.x cycle, and any dropped features would already have been deprecated before release. jQuery was trickier, but also higher risk to leave on an old version given that there are already disclosed security issues against older versions of jQuery and jQuery UI.)

It would be more semantic and safer to increment the major version when we have to make such major dependency updates. @catch, @larowlan, and I were discussing the above comment, and we agreed that we would probably increment the major version in that way when we have major dependency updates after 9.0.0.

However, at present, we really were not prepared to increment the major version number. Not only is all of our documentation, infrastructure, code, etc. still built around the expectation that there's D7 and D8, but the major version is also still very tied to "massive BC breaks and difficult upgrades" and "dropped support for Drupal N-2" in perceptions of Drupal generally. With 9/10ths of Drupal sites still on D7, I don't think we could really increment the major version without causing mass panic far more disruptive than the library updates themselves.

I think we'll take all this into account if we have to make a major version change for a major library in the future, and do what we can to make it less of a surprise, like announcing it a minor release ahead of time (which we did for the browser compatibility change).

All this isn't really what this issue is about -- it's about defining core's own JS APIs -- but I wanted to respond here since this is where the question was asked and it probably would come up again in discussion here.