Avoid using early stage TC39 proposals via babel

[Bargs]

Blocked by #5822

For background on the TC39 proposal process https://tc39.github.io/process-document/

Our current babel configuration allows usage of proposals all the way down to stage 1.

I think this is dangerous because any proposal that's not in stage 4 is subject to change and rejection. I can possibly see an argument for stage 3 since the expected changes to a proposal at that point are "Limited: only those deemed critical based on implementation experience". But we should definitely expect anything at stage 2 or below to change before it gets included in the spec, if it gets included at all.

IMO relying on these proposals is equivalent to relying on a bunch of unvetted polyfills that could change at any time, become unsupported at any time, and may never make it into the final spec. At stage 2 and below we should only include a polyfill if we think it stands on its own merits and is so useful that we would include it even if it never becomes part of the official language.

For a list of active proposals: https://github.com/tc39/proposals

[epixa]

From this point onward, we're going to adopt the official stance that we accept any stage 3 proposal or above. Since our babel version is out of date and can't yet be configured with explicit feature support, this will need to be an implicit understanding for the time being, but once we bump babel we'll codify that by explicitly allowing the stage 3.

Because the stage 2 class property syntax is already being used in many places, we are creating a temporary exception for this rule and will continue to allow it. When we bump babel, we'll make sure it accepts this specific proposal as well. If that proposal were to be rejected, we'll do a mass codeshift to remove it from our code.