400x faster with linear hashing of the hash map entries

[JaroslavTulach]

Pull Request Description

Fixes #5233 by removing EconomicMap & co. and using plain old good linear hashing. Fixes #8090 by introducing StorageEntry.removed() rather than copying the builder on each removal.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Java,
• All code has been tested:
  • Unit tests continue to pass
  • Check the effect on benchmarks

[JaroslavTulach]

I assume performance of the EnsoHashMap shall no longer be a problem.

org_enso_benchmarks_generated_Enso_Hash_Map_100000_Enso_Incremental achieves 4.06ms per operation which makes it slightly faster than org_enso_benchmarks_generated_Enso_Hash_Map_100000_Java_Incremental benchmark.

org_enso_benchmarks_generated_Enso_Hash_Map_100000_Enso_Replacement has been sped up 400 times and is now just 50% slower than the org_enso_benchmarks_generated_Enso_Hash_Map_100000_Java_Incremental - that's a good result given that the Java HashMap doesn't need to keep the referential transparency at all.

[hubertp]

Minor questions but other than that this looks nice!

[Akirathan]

Very nice performance improvement. Just few typos in javadoc.

[radeusgd]

I think I'm slightly confused.

Changing the ordering of elements of the Map shouldn't really change the way rename_columns works, at least in theory. I guess that if it did, we should look into it.

I believe the ordering is not most crucial, but the original behaviour presented in this test seems rather preferred - we want the column without suffix to be the first column on the list, not last.

@jdunkerley shall I create a small bug report so that we can amend rename_columns to work again like before with the new Map?