Fix lazy map hashtable regression

[yingsu00]

Resolves issue #12187

In 23de11f we lazily build the hashtables for map. It introduced a
regression for the case where the MapBlock is created through
AbstractMapBlock.getRegion(), in which the hashtables built on the
MapBlock region was not updated in the original MapBlock, thus causing
repeated hashtables build on the same base MapBlock. The change is to
encapsulate the int[] hashtables in AbstractMapBlock$HashTables object
and make it a member of MapBlock/MapBlockBuilder, so that when the
sliced MapBlock builds the hashtables, the base MapBlock would also gets
updated.

This PR was verified to fix the reported regression case on our verifier cluster.
Query CPU cost before the Lazy Map change: 57 min
Query CPU cost with Lazy Map change without this fix: > 50 days
Query CPU cost with Lazy Map change with this fix: 37 min

[wenleix]

I take a quick look into the PR, and I don't recommend to rush into the current release, and revert first, for the following reasons:

• I need a bit more thinking into the code, for example the getInstanceSize and getRetainedSize methods in HashTables. It doesn't look like a typical code style in Presto code base. I understand they are introduced since the retained size calculation in MapBlock and MapBlockBuilder are different so what's the right interface requires a bit more contemplation.

• Reverting the lazy MapBlock hash table build will have little product impact, since today the PartitionedOutputOperator will build the hash table when appending the data into MapBlockBuilder -- and my understanding is we already have a commit in the hotfix branch so it should take minimal work to prepare the revert PR.