LibJS: Transition ModuleEnvironment bindings to HashMap for efficiency

[ananas-dev]

This gives O(1) access to ModuleEnvironment bindings since it is only accessed by name.

[gmta]

@Imran-imtiaz48 please don't add LLM generated responses as a review.

[tcl3]

Are you sure this leads to a performance improvement? Could you run some Kraken and/or Octane benchmarks and post the results?

You can do that using the scripts in the js-benchmarks repository. The commands you run will look something like this:

(checkout the master branch (without your changes) and build it)
./run.py --iterations 2 --warmup 3 --suites Kraken,Octane --output before.json

(checkout the branch with your changes and build it)

./run.py --iterations 2 --warmup 3 --suites Kraken,Octane --output after.json

./compare.py -o before.json -n after.json

[awesomekling]

Are you sure this leads to a performance improvement? Could you run some Kraken and/or Octane benchmarks and post the results?

None of the benchmarks in our js-benchmarks collection use JS modules, so there should be no real difference from these changes.

Regardless, a benchmark would be good here, to illustrate the improvement being made.

For non-module environment accesses, we use a form of caching (see the EnvironmentCoordinate caches for e.g GetById.) Those caches depend on having contiguous indexed storage and would not work with an associative container like HashMap. Are we sure using a HashMap is the best solution here?