internal/runtime/maps: tune MinAeshashSize for arm64

Set the cutoff to 16 bytes on arm64, measured on my Apple M1 Max.
This is the throughput regime cross-over point.

16 is the value that popped out of the bakeoff benchmark I added.
Unlike with x86, where we picked 9, sizes from 9 to 15 want to go
through wyhash on ARM.

As with my x86 benchmarks, the throughput and latency cutoffs are
very different. I observed a cross-over for latency at 192, which
may be worth exploring in the future (see go.dev/issue/80970).

Benchmarks below are linker-randomized and interleaved to shake
out code layout and thermal drift issues (total n=18).

    MapGroupBy/Key=int64                4.73m   1.65m  -65.1%
    Hash5                               5.52n   3.24n  -41.3%
    ComplexAlgMap                      23.98n  17.86n  -25.5%
    MapAssignExists/int64/len=6         6.00n   4.85n  -19.2%
    MapCycle                           19.75n  16.23n  -17.8%
    MapAssignExists/int64/len=65536    10.07n   8.48n  -15.8%
    MapGroupBy/Key=string               3.15m   2.69m  -14.6%
    MapAssignFillHint/int64/len=65536  16.05n  14.15n  -11.8%
    MapAccessHit/int64/len=65536        8.82n   7.91n  -10.3%
    MapAccessMiss/int64/len=65536       8.12n   7.36n   -9.4%
    MapDelete/int64/len=65536          51.91n  48.40n   -6.8%
    HashStringSpeed                     8.30n   7.78n   -6.4%
    MapAccessHit/string/len=65536      12.38n  11.88n   -4.0%
    MapAccessHit/int64/len=6            4.47n   4.43n       ~
    Hash16                              2.92n   2.90n       ~
    Hash64                              4.02n   4.02n       ~
    MapPopulate/1000                   41.14µ  43.25µ   +5.1%
    MapPop/Key=*int32/len=65536          241n    271n  +12.4%
    MapPop/Key=int32/len=65536           216n    255n  +18.2%
    MapPop/Key=int64/len=65536           222n    273n  +23.1%

Everything not shown did not change. Geomean is -3.8%. Yes, that is
a statistically-significant 65% improvement for the aggregation
benchmark I added.

Now, this is not pure gains, because MapPop regressed by around 20%.
This checks the performance of "grab a random element and delete it".
This benchmark is very old and is a backstop against quadratic behavior
of the pre-swiss implementation. The regression is not ideal, but I
think this is a rare type of map operation, and I think it's fine to
trade it off given how many other benchmarks improved.

Change-Id: I6a34322155e9a39e6f4cbd8a617dc9202a38ef52
Reviewed-on: https://go-review.googlesource.com/c/go/+/818500
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>