Use a dynamic import instead of the <script> hack

[antocuni]

This PR is based on #1258 and must be merged only after that. The only relevant commit is 57fed98.

As the title says, we want to use a dynamic import() to fetch and load pyodide, instead of dynamically adding a <script> tag to the page.

This greatly simplifies the logic for loading the interpreter and for handling user errors. In particular, until now we had to manually call handleUserError because afterInterpreterLoad was an async function called in response of a browser event.
Now, it's a normal async function called from another async function, so the error is automatically propagated up to main(), where it's correctly handled by the try/catch:

pyscript/pyscriptjs/src/main.ts

Lines 108 to 114 in 57fed98

	async main() {
	try {
	await this._realMain();
	} catch (error) {
	await this._handleUserErrorMaybe(error);
	}
	}

[WebReflection]

@antocuni I agree with the commented text and I am not a big fun of using modules to side-effect on the global context like we've always done (unless these are polyfills) ... although I think the commit "that matters" looks perfectly fine, so I'd be OK with that change as it surely simplifies the dance around importing that functionality 👍

P.S. I know Firefox is not there yet, but I hope we won't create too much documentation around this side-effect and switch to a proper ECMAScript module as soon as Firefox catches up with modules in workers 🤞

P.S.2 I can't somehow approve this MR for some reason 🤔 ... but maybe CI failing is to blame

[hoodmane]

57fed98 looks good to me.

[antocuni]

@antocuni I agree with the commented text and I am not a big fun of using modules to side-effect on the global context like we've always done (unless these are polyfills) ... although I think the commit "that matters" looks perfectly fine, so I'd be OK with that change as it surely simplifies the dance around importing that functionality +1

P.S. I know Firefox is not there yet, but I hope we won't create too much documentation around this side-effect and switch to a proper ECMAScript module as soon as Firefox catches up with modules in workers

yes, even if I'm not a JS expert I can see that modules are clearly superiors. I'll be happy to switch to proper modules as soon as firefox catches up.

---

For the sake of future readers: I have rebased the branch on top of main, and what was known as commit 57fed98 is now 2295b16. I will merge it as soon as the tests are passing

[hoodmane]

So I guess the plan is that when we move to using a worker we can change the code here to:

if(inClassicWorker) {
   importScripts(interpreterURL);
} else {
   await import(interpreterURL);
}

[antocuni]

So I guess the plan is that when we move to using a worker we can change the code here to:

if(inClassicWorker) {
   importScripts(interpreterURL);
} else {
   await import(interpreterURL);
}

Yes exactly