Various HashMap optimisations

[utdemir]

Just some minor optimisations for our HashMap implementation. It contains
a few unrelated small changes, so reviewing each individual commit might
be easier.

When I compare this against Data.HashMap.Strict, the results change based
on the input (likely based on the hash distribution of the key). I need to investigate
this more. Just as reference, here're the functions I am comparing (Key is just a
newtype wrapper around Int):

   linear :: [Key] -> HashMap.Linear.HashMap Key () %1-> ()
   linear inp hm = go inp hm `Linear.lseq` ()
    where
     go :: [Key] -> HashMap.Linear.HashMap Key () %1-> HashMap.Linear.HashMap Key ()
     go [] h = h
     go (x:xs) h = go xs Linear.$! HashMap.Linear.insert x () h

   dataHashMap :: [Key] -> Data.HashMap.Strict.HashMap Key () -> ()
   dataHashMap inp hm = go inp hm `seq` ()
    where
     go :: [Key] -> Data.HashMap.Strict.HashMap Key () -> Data.HashMap.Strict.HashMap Key ()
     go [] h = h
     go (x:xs) h = go xs $! Data.HashMap.Strict.insert x () h

I did not include the benchmark on this PR, since it looks a bit different
than our existing HashMap benchmarks. I have to combine them together at
one point.

[aspiwack]

I guess that the next step is committing these benchmarks.

[facundominguez]

Hello! Just a random thought, are alter and alterF supposed to be inlined? Otherwise, the allocation of the Maybe value returned by the callback can't be eliminated. insert in unordered-containers isn't implemented in terms of alter, at least.

[utdemir]

are alter and alterF supposed to be inlined? Otherwise, the allocation of the Maybe value returned by the callback can't be eliminated.

This was a good point, I think they should be inlined. I can observe from the core output that both the callback passed to alterF from alter and eg. callback pased to alter from insert disappear. Unfortunately they do not correspond to a measurable speed increase on the insertion benchmarks, I think this is because they are only called once per insertion, but our bottleneck is on tryInsertAtIndex and probeFrom functions which are called multiple times per insertion.

But they make sense and make the core output prettier, so I commited those.