ffmpeg.wasm is not "technically" production ready!

I believe it makes sense to add an option to disable the WASM threads and use a single core (be it that it makes it slower). ffmpeg.js is massive and extremely slow and does not support most of the options we need, so it is not an option for us. At the same time, any attempt to use CORP and COEP disables Stripe, Intercom, and many other necessary integrations on our production website, which in effect makes ffmpeg.wasm not production-ready.

What happened to SharedArrayBuffer after the Spectre is fairly new and it's going to take some time for all the other companies out there to jump on the cross-origin isolation bandwagon.

Currently, there is only one way to use ffmpeg.wasm in production, which is by signing up for an [origin trial](https://developer.chrome.com/blog/enabling-shared-array-buffer/#origin-trial) to be able to use SharedArrayBuffers without cross-origin isolation, but this only works on Chrome, and only until Chrome 103, after which we are back to square one. There is some hope according to [this article](https://web.dev/coop-coep/) that options like `Cross-Origin-Opener-Policy: same-origin-allow-popups` might work in the future, but no one knows yet how many of those integrations would break again, back to my initial statement, without this option ffmpeg.wasm is not going to be actually production-ready.

-----------------
_Originally posted in https://github.com/ffmpegwasm/ffmpeg.wasm/issues/137#issuecomment-975383348_