Security Fix (sandboxed iframe)

[nbriz]

previously, a bad actor could create a sketch to exfiltrate a user's localStorage (including LLM keys if target user had those saved) and/or do GitHub things on the target user's account (if they were logged in). We've now blocked that by editing the main.js file so that the NNE.iframe gets sandbox="allow-scripts allow-forms allow-popups allow-modals allow-pointer-lock", no allow-same-origin. This gives the iframe a null origin, blocking malicious shared sketches from reading localStorage or making credentialed same-site requests to the GitHub API. Unfortunatley, this simple edit had breaking side-effects. These have now also been addressed:

1. the tutorial-maker and the project-files widget can't work with a sand-boxed iframe because they need the Service Worker to resolve requests for files/data stored in indexedDB (which it would no longer have access to), so when a student is working on a project (or an educator works on a tutorial) those widgets now remove the sandbox (in _initServiceWorker() for project-files and in _setCustomRenderer for tutorial-maker) then restore it on closeProject()/_quitTutorial() when returning to sketch mode.

2. the sandbox'd iframe's null origin causes browsers to treat all iframe requests as cross-origin. which means assets that previously loaded fine (like <img src="cd.gif">, but also fonts in templates and other files served via alias routes) were being blocked. So now server.js and routes.js have been edited with Access-Control-Allow-Origin: *, this is now set on all static file responses. I've doubled checked that this is safe for public content and doesn't open up any new attack vectors (can not be combined with credentialed requests), it just means other folks can fetch() any of our public files (which is fine).

3. a couple postMessage calls (for handling bg movement when mouse moves) in utils.js stopped working because without an explicit targetOrigin, the browser uses the sender's own origin as the default target, but a null-origin iframe can't target 'https://netnet.studio' that way, and the parent can't target 'null' as a valid recipient. we're now passing '*' in the postMessages to bypass that check and let the messages between iframe/netnet through.

4. the special error cases (see errMsgr in utils.setCustomRenderer) had to be augmented because one special error that was handled by the netitor for checking for CORS issues no longer worked withe the sandboxed iframe. this means removing the _checkForCORSerr logic from the netitor (since it won't work anymore) and migrating that logic into the custom errMsgr listeners and accompanying logic in the code-review widget. This meant some refactoring of that widget (which also came with an extra bug fix: special errors no longer remove other errors from the code review list as it would before). I've added a NOTE comment with more details in case we need to edit/refactor any of this for other reasons in the future.

NOTE: this attack vector is still present if the student is working on a project or working on a tutorial, which isn't an issue if they're working on their own project/tutorial, but can be an issue if they fork someone else's project and/or open someone else's custom tutorial in the tutorial-maker. For this reason I've also added warnings to the convo netnet has with students before they fork a project as well as to the main page of the tutorial maker widget.

[nbriz]

seems this has another side effect, with a sandboxed null-origin iframe you can't use camera/mic/geo, which means you can't do any of the camera demos. this will require a different approach to the sandboxing logic all-together to fix. I'll push that to this PR (along with other on-going security fixes) once that's ready (will also rename this PR at that point as it'll contain multiple security fixes, not just iframe sandbox stuff)