Workerized emscripten retroarch (WIP)

[JoeOsborn]

This PR removes the need for asyncify in retroarch web, and ports the web player away from BrowserFS to the modern Emscripten WASMFS, with backends for asynchronous fetch and for OPFS (origin private file system).

This patch eliminates the need for asyncify and uses modern filesystem APIs instead of the deprecated, unmaintained BrowserFS. I also added a new emscripten graphics backend for using webgl directly instead of (buggy) egl emulation.

This is a WIP patch because it won't fully work until some Emscripten PRs land and are released:

• Fix re-creating webgl context for offscreen canvas emscripten-core/emscripten#23518
• WIP: WASMFS chunked fetch backend emscripten-core/emscripten#23021 (I found a workaround, don't need this one)

The former fixes an offscreen canvas context recreation bug, and the latter adds an equivalent to BrowserFS's XHR filesystem (but without the hazardous running-XHR-on-the-main-thread problem).

The biggest issue is that local storage of users who were using the old version of the webplayer will be gone when they switch to the new webplayer. I don't have a good story for converting the old BrowserFS
IDBFS contents into the new OPFS filesystem (the move is worth doing because OPFS supports seeking and reading only bits of a file, and because BrowserFS is dead, and because of the performance costs of asyncify).

I've kept around the old libretro webplayer under pkg/emscripten/libretro-classic, and with these make flags you can build a non-workerized RA that uses asyncify to sleep as before:

    make -f Makefile.emscripten libretro=$CORE HAVE_WORKER=0 HAVE_WASMFS=0 PTHREAD=0 HAVE_AL=1

I also moved the default directory for core content on emscripten to not be a subdirectory of the local filesystem mount, because it's confusing to have a subdirectory that's lazily fetched and not mirrored to the local storage. I think it won't impact existing users of the classic web player because they already have a retroarch.cfg in place.

Note: I know I need to rebase this on latest master, and to integrate with the other recent emscripten patches. I'm aware of that and will work on that over the coming week.

[BinBashBanana]

Ideally a canvas ID could be specified somehow (instead of just using #canvas), similar to specialHTMLTargets, so that multiple instances could run on the same page without iframes (#15688)

[JoeOsborn]

Interestingly, with the deprecated lookup behavior #canvas refers to module.canvas, so multiple RA instances should work just fine.

specialHTMLTargets actually doesn’t work in multithreaded/worker situations since it’s per-thread.

[LibretroAdmin]

Hi, can the conflicts be resolved?

[JoeOsborn]

Yep, I'll work on that tomorrow probably. I wanted to get the PR up because it's been sitting on a branch a while and I thought maintainers might want a heads up

[JoeOsborn]

This wasn’t ready yet, can it be reverted? The wip tag was there because it’s a draft. I still have resizing and startup performance bugs to fix

[LibretroAdmin]

My bad.