import defer test bugs

[woess]

While implementing support for import defer, I think I've found the following bugs in the import-defer tests:

1. language/import/import-defer/evaluation-top-level-await/flattening-order/main.js:
   The test expects "5" twice. I don't see how that could happen, the second (last) "5" should be removed:
   

   test262/test/language/import/import-defer/evaluation-top-level-await/flattening-order/main.js

   Line 67 in 9d8efae

   "5"

2. language/import/import-defer/errors/get-self-while-defer-evaluating/main.js:
   I don't see how the assertion can pass before the evaluation trigger (ns.foo). The lines probably just need to be swapped?
   

   test262/test/language/import/import-defer/errors/get-self-while-defer-evaluating/main.js

   Lines 38 to 42 in 9d8efae

   	import defer * as ns from "./dep_FIXTURE.js";
   	assert(globalThis["error on ns.foo"] instanceof TypeError, "ns.foo while evaluating throws a TypeError");
   	ns.foo;

3. language/import/import-defer/errors/module-throws/defer-import-after-evaluation.js:
   In order for assert.sameValue(err1, err2) to be pass, both imported modules need to produce the same error (they don't). So I guess the import in import-defer-throws_FIXTURE.js was supposed to import throws_FIXTURE.js rather than itself, i.e.:

-import defer * as ns from "./import-defer-throws_FIXTURE.js";
+import defer * as ns from "./throws_FIXTURE.js";

4. language/import/import-defer/deferred-namespace-object/exotic-object-behavior.js:
   

   test262/test/language/import/import-defer/deferred-namespace-object/exotic-object-behavior.js

   Lines 46 to 51 in 9d8efae

   	verifyProperty(ns, "foo", {
   	value: 1,
   	writable: true,
   	enumerable: true,
   	configurable: false,
   	});

   
   This one's tricky: While the test is technically verifying the correct thing, I believe verifyProperty cannot be used in this case because it not only checks the property descriptor but also tries to verify actual writability by setting a new value, but module namespace exotic object properties aren't truly writable in the sense that writes (aka [[Set]], [[DefineOwnProperty]]) don't have any effect/don't succeed.

[nicolo-ribaudo]

Thank you! All of these seem like bugs indeed.

@takikawa Given that you were running these tests in WebKit, did you happen to find these bugs too?

[takikawa]

@nicolo-ribaudo These all did fail on WebKit too (and are currently set to expected fail), but I think at least for 1 & 3 it's because it was masked by other bugs in WebKit module loading.

For 2 & 4 I think I just didn't catch the bugs, for 2 it does pass after making the proposed change. I can test 4 if there's a fix.