Disable import-assertions tests

[Constellation]

As it gets stage-2 and syntax change can be possible, we should disable import-assertions tests.

[ptomato]

I was curious if we had any tests for other features that had been demoted to stage 2, so this motivated me to go clean up the features.txt file: #3782

There are still tests in the corpus for cleanupSome which was split off at stage 2, as well as import assertions. Also, this made me realize that import assertions being at stage 2 leaves the status of JSON modules somewhat unclear. I guess JSON modules are technically still stage 3 but temporarily unimplementable because the language lacks the syntax with which to express them?

Because of this, my preference would be to leave the import assertions tests as they are, and just recommend that implementations filter out the import-assertions and json-modules flag, as they already do with FinalizationRegistry.prototype.cleanupSome. This opinion is based purely on what I estimate would be most convenient. If it turns out that's inconvenient for implementations, I wouldn't mind removing them, but in that case let's at least immediately open a PR reverting the removal, so that the burden isn't on the test262 maintainers to remember, "hey, we have tests for that somewhere in the git log."

[ljharb]

Given that communication with prose isn't as reliable, my preference would be to remove them and immediately open up the revert PR.

I agree that JSON modules is currently unimplementable until import assertions becomes stage 3 again.

[sosukesuzuki]

Import assertions have become import attributes, which have now reached stage 3. Can we disable tests for import assertions now?

[nicolo-ribaudo]

The proposal still includes assert as deprecated. The plan is to fully remove it once Chrome successfully unships it (during the summer) — then we can remove the tests.

https://tc39.es/proposal-import-attributes/#sec-deprecated-assert-keyword-for-import-attributes