Binaryen-related micro optimizations

[stevenwdv]

This should shave a couple seconds off wasm-emscripten-finalize, which is really slow for me (more with source maps & stack overflow detection enabled, which I didn't look at here (yet)). Didn't make as much of a different as I'd hoped, but anyway.

1. I'm doing this mostly without understanding the inner workings, focusing on the C++ side.
2. Not sure what to do with third_party/llvm-project/dwarf2yaml.cpp, since it comes from LLVM. I did also submit dwarf2yaml.cpp optimizations llvm/llvm-project#179048 but their version is very different, and not only in the XXX BINARYEN areas.
3. Please check that the removal of locationUpdater.has*() usages is correct. It seems that the result is almost identical. If the subtle difference is relevant, I can merge the two functions in a different way, wrapping in optional but also allowing 0 if the old location was found but the new wasn't.
4. Maybe the Y.AbbrevDecls.reserve using the loop is a bit overkill since I think the performace impact was minimal, I can remove it if you want.

---

When built with -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_MIMALLOC=ON -DBYN_ENABLE_LTO=ON -DBUILD_STATIC_LIB=ON -DBYN_ENABLE_ASSERTIONS=OFF:

wasm-emscripten-finalize -g --bigint --no-dyncalls --no-legalize-javascript-ffi --dwarf thing.wasm -o thing-finalized.wasm --detect-features

Pre: 19s

Post: 16.5s

[kripken]

I like the changes to wasm-debug.cpp, but I am hesitant to make changes to LLVM files. Such changes will make updating and figuring out bugs much more difficult, potentially.

If there were a big perf difference I might feel otherwise, but that doesn't sound like the case? What is the benefit of the changes to this file specifically?