Allow wasm-eval instead of unsafe-eval in the browser extension manifest

[mossroy]

This is a follow-up of #751 : unsafe-eval was needed to allow WASM in chromium extensions. The goal of this issue to allow only what is necessary.

Problem is that the CSP that forced us to do that has been introduced at the beginning of 2017 (https://codereview.chromium.org/2646713002/), and the wasm-eval has been implemented at the end of 2017 (https://bugs.chromium.org/p/v8/issues/detail?id=7041). So switching to wasm-eval would break compatibility with the chromium-based browsers of 2017.

So I suggest to also try to trap this specific exception, and automatically fallback to ASM in this case. It would only occur for these browsers of 2017 (rare case), and would allow them to work anyway. It's not a big issue if they use ASM instead of WASM.

[mossroy]

Maybe another way would be to sandbox the page that loads the wasm : https://developer.chrome.com/docs/extensions/mv2/sandboxingEval/ , as suggested in https://stackoverflow.com/questions/48523118/wasm-module-compile-error-in-chrome-extension But this page is currently www/index.html so it's probably complicated to sandbox it

[Jaifroid]

There are a couple of Chromium-only wasm-related CSP directives. What is needed under MV3 (Manifest V3) is incorporated into #984. Note that there is no eval allowed at all under that manifest version. Therefore, realistically, to run Zimit-based archives, we needed to introduce the PWA into the Chromium extension, as an option, alongside "local" use of the Service Worker. A PR #1000 implementing the remote SW mode has now been merged into main.