adjustments to HostEnsureCanCompileStrings discard value

[mikesamuel]

https://github.com/WICG/trusted-types/blob/1f0e41ff742de43e70261814ac2b2d314b630e1e/spec/index.bs#L1430-L1446

This uses Get Trusted Type compliant string which might apply the default policy.
This is the right thing to do so that applications can provide minimal workarounds for legacy code patterns like

const globalObject = new Function('return this;')();

which appears frequently in JS library code.

---

Uses in the JS spec are written like

1. Perform ? HostEnsureCanCompileStrings(evalRealm, evalRealm).

The return a value is never used: it either throws or returns normally.

---

This causes two problems:

1. Any adjustments made by the policy are lost, so a policy like

   TrustedTypes.createPolicy('default', {
     createScript(x) { return rewriteJavascript(x); }
   });

   the value that will reach CreateDynamicFunction will be x, not rewriteJavascript(x).
2. Any non-trusted types value will be stringified twice which will cause unnecessary
   visible side-effects for values like

   let stringifyCallCount = 0;
   f = new Function({
     toString() {
       return stringifyCallCount++ ? 'evil()' : 'good()'
     });
   

   which might cause the policy to see 'good()' but CreateDynamicFunction to receive 'bad()'.

[mikesamuel]

AFAICT, there's no fix that satisfies the const globalObject = new Function('return this;')(); use case and which does not require changing the nature of the JS / browser interactions.

@mikewest Do you have a sense of how browser implementors might react to replacing language like

1. Perform HostEnsureCanCompileStrings(calleeRealm, callerRealm, goal, sourceText).

with

1. Set sourceText to HostBeforeCompile(calleeRealm, callerRealm, goal, sourceText).

(tc39/ecma262#1498 defines goal and sourceText.)

[koto]

Should this be tracked under #207 or the tc39 repos, or do we need this bug separately?