Refactor mwoffliner logic behind CSS/JS modules handling

[VadimKovalenkoSNF]

Before multiple render implementations, mwoffliner handled article modules and static files the same way for page/mobile-section output and page/html since they both relied on the same JS/CSS. Now, when WikimediaMobile render has been introduced in https://github.com/openzim/mwoffliner/pull/1903, additional external resources are required for page/mobile-html along with static files with overriding styles and scripts.

Though the render process has been separated into related classes, modules handling didn't because mwoffliner doesn't have information about chosen renderer across the entire application and hence when to choose between desktop / mobile modules to save them into the zim - this process happens in src/mwoffliner.lib.ts and in fact, it doesn't know anything about exact renderer (because there might be the case where we implicit use another render API as a fallback). A possible solution to this is to keep the rendered name in the dump.opts so the execution process can rely on it and write correct modules into the zim. This, however, might lead to refactoring other pieces of code such as saveArticles() and downloader.getModuleDependencies()

[Jaifroid]

Can I just urge that we don't re-introduce inline JS code that cannot run in Manifest v3 extensions (and in MV2 extensions in Chromium browsers)? It would be great if there could be a period of testing any ZIMs produced to spot any issues in readers before going live.

[kelson42]

@Jaifroid Inline JS is taboo and I have already transmitted this information to @VadimKovalenkoSNF. We will start soon the testing of MWoffliner 1.14.0, but here there is no PR for this ticket yet.

[Jaifroid]

OK, thanks for the reassurance! I'll be happy to test new versions when ready.