Python test runner umbrella issue

[ojeytonwilliams]

After #52526 goes in, the following issues will need addressing:

MVP

• Make sure the service worker isn't cached. i.e. merge feat: prevent caching of python-input-sw.js client-config#11 and deploy a new version
• Make sure the service worker, client/static/python-input-sw.js, updates if we need to change it.
• Replace e.code.original["main.py"] with code

i18n (post-MVP)

• Update the translation parser to handle Python comments

Nice to have

• Support asyncio, if possible. Pyodide does have a custom event loop (documented here and introduced in Add simple web loop pyodide/pyodide#1158 ) which is limited, but may be sufficient for our needs.
• Make sure xterm.css is cached and that different versions have different filenames.
• Python(UI): add ways to control the execution of the user's code #52538
• Host pyodide's source ourselves i.e. add the files to the cdn and reference it with indexURL
• Support testing of print calls and/or give tests access to stdout.
• Proxy errors to the console. We don't need to redirect stdout, since the terminal shows that, but errors do need to be shown ref. Improve error messages in the Python curriculum console #52411
• If we're running tests in parallel, update the service worker to handle multiple concurrent input requests

Refactors

• Put code shared between test-evaluator and python-test-evaluator into a common module
• Rather than using createTerminal to open and prepare term, use an async constructor to instantiate an object

At some point

• Allow interruption of pyodide. This is quite hard because the security requirements for SharedArrayBuffer are high. As it stands, we cannot enable those headers and working out how (or even if) we can enable them is an involved process. First thing to do is to test interrupts locally to make 100% sure the UX is good (i.e. that it's significantly quicker to interrupt an infinite loop or a blocking input call than simply terminating and recreating the worker). If it's not, there's no need to investigate further.
• If that is not feasible, one alternative is to allow cancellation of blocking input from the main thread. This would only be a partial solution, however. If, for example, the python runs an infinite loop, it would not be possible to cancel it without terminating the entire worker.

[ShaunSHamilton]

UI: add buttons to run and cancel the learner's code

Instead of this, I still think having Campers type out python3 main.py in the terminal/preview/console thing is better.

Proxy errors to the console. We don't need to redirect stdout, since the terminal shows that, but errors do need to be shown ref. #52411

Personally, I have always disliked having a "Shell" and a "Console" (e.g. Replit). I would prefer we not do the same, and, instead have a single terminal we:

1. Allow campers to type in
2. Show the output of running the code in

I do not see benefit from further separating the experience to an actual dev/local environment.

[gikf]

I don't know where exactly put it on the list, so I'm linking here another python test runner issue: #52448