runtime: amortize zeroing and its publication for small-object spans #81393

Problem

Currently allocations that need zeroed memory (this includes all from
scannable spans and some from noscan spans) pay the cost per object — a
small memclr and a publication barrier after it, repeated for every
slot of a span.

For noscan objects the publication barrier only matters to the program:
no pointer bits are recorded for them, so the GC never scans their
contents. The barrier merely ensures that code that observes the
noscan object through the allocated pointer sees zeros rather than
stale memory. A noscan allocation that does not need zeroing
(mallocgc with needzero=false) therefore has nothing to order;
ordering belongs to the caller (see #77074). And zeroing such
allocations in advance is pure waste.

For scannable objects the barrier needs to stay per-object to order
both the contents and the heap bits, but the (always required) zeroing
amortizes just the same.

Proposal

When an allocation with needzero=true triggers a refill of a span whose
live objects form a dense prefix (allocCount == freeindex; every empty
span qualifies), zero the span's free object slots in one bulk operation
and mark the span pre-zeroed (span.needzero = 0), so every subsequent
allocation from that span skips its per-object zeroing:

• refill zeroes the free slots [freeindex*elemsize, s.limit) when
  the span is not already pre-zeroed; one publication barrier after the
  clear orders it for the whole span.
• For needzero=false refill does nothing: the span may keep serving
  allocations that don't need zeroing, and any that do are zeroed
  individually, as today (span.needzero stays 1); once recycled, a
  needzero=true refill can still bulk-zero it.
• Tiny and noscan allocations gate both the zeroing and its publication
  barrier on span.needzero != 0.

Safety rests on the existing invariant freeindex <= allocCount:

• at refill every slot below freeindex is allocated, so
  allocCount == freeindex implies no live object at or above it.
• sweep resets freeindex to 0 and allocCount to the live count, and
  sets span.needzero=1 whenever it frees an object.

Experiment results

Microbenchmarks, geomean vs base (n=10, GOMAXPROCS=1), by benchmark family (MakeSlice includes its Copy variants, AppendSlice includes AppendSliceLarge):

On Kunpeng 920 all 158 Mallocgc subbenchmarks win.
On the Xeon per-object zeroing is cheap and the publication barrier is a no-op, leaving little to amortize.

Threading needzero into refill prevents 18–35% regressions on large AppendSlice benchmarks, the same kind of waste CL 359477 removed from mheap.alloc.

sweet benchmarks (markdown, gopher-lua, bleve-index, esbuild, etcd, tile38) and go-build: