Cherry-picks for the 3.x branch (future 3.6) - 17th batch

[akien-mga]

Thirdparty and buildsystem cherry-picks.

The Web/Javascript buildsystem changes will need some testing, ideally we should ensure that we still support the following Emscripten versions:

• 3.1.39: Currently used for 3.6 standard builds
• 3.1.14: Currently used for 3.5 standard builds, and not planning to change it
• 1.39.9: Currently used for Mono builds (both 3.5 and 3.6), limited by upstream Mono support
• 3.1.58: Latest upstream release, we should aim to support it in 3.6 at least, ideally 3.5 too if we can

But these commits aim to also add support for latest Emscripten versions, which users tend to try to use, and run into all kinds of issues as Emscripten breaks compat in patch releases regularly.

CC @godotengine/web

[akien-mga]

I'm getting this error with a web editor closure compiler build:

$ scons p=javascript tools=yes use_closure_compiler=yes threads_enabled=yes target=release_debug

...

/usr/bin/node /home/akien/Godot/toolchains/emsdk/upstream/emscripten/node_modules/.bin/google-closure-compiler --compilation_level ADVANCED_OPTIMIZATIONS --externs /home/akien/Godot/godot-3.x/platform/javascript/js/engine/engine.externs.js --js /home/akien/Godot/godot-3.x/platform/javascript/js/engine/preloader.js --js /home/akien/Godot/godot-3.x/platform/javascript/js/engine/config.js --js /home/akien/Godot/godot-3.x/platform/javascript/js/engine/engine.js --js_output_file /home/akien/Godot/godot-3.x/bin/godot.javascript.opt.tools.threads.engine.js
Install file: "misc/dist/html/logo.svg" as "bin/.javascript_zip/logo.svg"
Install file: "misc/dist/html/manifest.json" as "bin/.javascript_zip/manifest.json"
Install file: "misc/dist/html/offline.html" as "bin/.javascript_zip/offline.html"
Creating 'bin/godot.javascript.opt.tools.threads.service.worker.js'
Install file: "bin/godot.javascript.opt.tools.threads.service.worker.js" as "bin/.javascript_zip/service.worker.js"
progress_finish(["progress_finish"], [])
/home/akien/Godot/godot-3.x/platform/javascript/js/engine/config.js:320:4: WARNING - [JSC_TYPE_MISMATCH] assignment to property canvas of Config
found   : Element
required: (HTMLCanvasElement|null)
  320|                          this.canvas = nodes[0];
                                ^^^^^^^^^^^^^^^^^^^^^^

0 error(s), 1 warning(s), 71.5% typed
Linking Static Library ==> core/libcore.javascript.opt.tools.threads.a
Ranlib Library         ==> core/libcore.javascript.opt.tools.threads.a
Linking Program        ==> bin/godot.javascript.opt.tools.threads.js
em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]
cache:INFO: generating system asset: symbol_lists/f98dc34baf30d1ff1d511f1024294f0972a79866.json... (this will be cached in "/home/akien/Godot/toolchains/emsdk/upstream/emscripten/cache/symbol_lists/f98dc34baf30d1ff1d511f1024294f0972a79866.json" for subsequent builds)
cache:INFO:  - ok
wasm-ld: warning: function signature mismatch: unztell
>>> defined as (i32) -> i64 in core/libcore.javascript.opt.tools.threads.a(file_access_zip.javascript.opt.tools.threads.o)
>>> defined as (i32) -> i32 in core/libcore.javascript.opt.tools.threads.a(unzip.javascript.opt.tools.threads.o)
Install file: "bin/godot.javascript.opt.tools.threads.wasm" as "bin/.javascript_zip/godot.tools.wasm"
Creating 'bin/godot.javascript.opt.tools.threads.wrapped.js'
Install file: "bin/godot.javascript.opt.tools.threads.worker.js" as "bin/.javascript_zip/godot.tools.worker.js"
scons: *** [bin/.javascript_zip/godot.tools.worker.js] bin/godot.javascript.opt.tools.threads.worker.js: No such file or directory
scons: building terminated because of errors.

The godot.javascript.opt.tools.threads.worker.js seems to be written to the repo root folder instead of in bin/.

[lawnjelly]

I'll try and test this out locally once we've solved the closure problem.

[akien-mga]

The web build issue doesn't seem to be caused by this PR per se, it must be another issue with recent Emscripten that this PR doesn't fix yet. I tested with 3.1.39 (current version we use for 3.6 builds) and there's no regression between 3.x and this PR.