Consider disabling the shuffling allocator by default

[cfallin]

A recent report by @d-sonuga indicates wildly differing data when measuring the impact of regalloc improvements on compile time depending on whether Sightglass's shuffling allocator is enabled or not: in his case, less prominent gains. On the other side, we've had instances in the past where we make improvements to Cranelift to reduce allocations and we see bigger gains under Sightglass that don't materialize into real savings in production.

The shuffling allocator was chosen in order to avoid measurement bias due to incidental details of memory layout. However, I'm concerned that in removing that source of error, we've also swamped the real signal, and are getting very misleading results. The end goal of benchmark measurement should be to drive a feedback loop that improves experience for end-users; to that end, it is likely better that we use the normal allocator by default, so we see gains in their proper proportions.

cc @fitzgen, @abrown, thoughts?

[fitzgen]

Yeah, seems fine by me.

Alternatively/additionally, if anyone wants to improve the perf of the shuffling allocator itself, that is also very welcome! There is no fundamental reason it should add so much overhead.

[abrown]

Sounds ok to me.