perf: use unordered_set for Name sets for better compile speed

[Changqing-JING]

wasm::Name has an O(1) pointer-based hash but operator< does O(n) memcmp, making std::set<Name> unnecessarily slow. On large workloads, ~35% of wasm-opt CPU time was spent in __memcmp_evex_movbe inside EffectAnalyzer::walk called from CodeFolding. Switching the four std::set<Name> fields in EffectAnalyzer, NameSet in branch-utils.h, and the local containers in CodeFolding to their unordered equivalents eliminates the bottleneck.

[kripken]

@Changqing-JING what workloads did you test on?

I ran a test with a large Java testcase. Instruction counts, branches, and walltime were within noise.

If you are seeing 35% on this code, perhaps there is something special in your testcase? In general, the number of globals and break targets is very small, so a normal set can do well (by saving the time it takes to do hashing).

[Changqing-JING]

@kripken Thank you for review

1. Yes, it's reproduced when a br_table has large amout of targets. Background story is, in assemblyscript GC, it uses br_table type_rtid to dispatching the gc visitor. In a large app, when there are large amount of types, then the CodeFolding become very slow.
   It can be reproduced with this testcase
   https://github.com/Changqing-JING/assemblyscript/blob/slow-compile/test.ts

time node ./bin/asc.js -O2 -o build/test.wasm ./test.ts 

real    6m27.324s
user    6m19.690s
sys     0m11.712s

For better understanding of this problem, I created an example to emulate the assemblyscript case
https://github.com/Changqing-JING/BinaryenLearn/blob/binaryen-slow-pass/flamegraph.sh

2. I can share the flamegraph
   

3. The flamegraph shows, even though the set and map saved time from hashing, but operator< of wasm::Name costed more. So that map saving time from hashing is majorly benifit for number key e.g. wasm::Index, because compare the key is cheap, but when the key is string, it's not that case, especially when the string is long and having same prefix.

4. Base on 3, the problem is hard to be reproduced by wasm-opt, because wasm-opt use auto indexing label name like $block1. But when binaryen is used as a lib of a frontend compiler, the name can be long like $__inlined_func$~lib/rt/itcms/Object#unlink$81, then the strcmp costs much longer time.