fix: avoid deadlock in TestStringPoolRaceCondition

[egibs]

Follow-up for #1394

This PR fixes a flake with the TestStringPoolRaceCondition test where large numbers of goroutines calling .clear() will cause a deadlock because new calls to clear the map attempt a new resize while earlier resizes are stuck on waitForResize:

func (m *Map[K, V]) helpResize(seq uint64) {
	for {
		table := m.table.Load()
		nextTable := m.nextTable.Load()
		if resizeSeq(m.resizeCtl.Load()) == seq {
			if nextTable == nil || nextTable == table {
				// Carry on until the next table is set by the main
				// resize goroutine or until the resize finishes.
				runtime.Gosched()
				continue
			}
			// The resize is still in-progress, so let's try registering
			// as a helper.
			for {
				ctl := m.resizeCtl.Load()
				if resizeSeq(ctl) != seq || resizeHelpers(ctl) >= uint64(maxResizeHelpers) {
					// The resize has ended or there are too many helpers.
					break
				}
				if m.resizeCtl.CompareAndSwap(ctl, ctl+1) {
					// Yay, we're a resize helper!
					m.transfer(table, nextTable)
					// Don't forget to unregister as a helper.
					m.resizeCtl.Add(^uint64(0))
					break
				}
			}
			m.waitForResize()
		}
		break
	}
}
//
func (m *Map[K, V]) waitForResize() {
	m.resizeMu.Lock()
	for resizeSeq(m.resizeCtl.Load())&1 == 1 {
		m.resizeCond.Wait()
	}
	m.resizeMu.Unlock()
}

We only call this once per match processor in real usage anyway, so even the lower number of iterations is much more of a stress test than what we'd encounter during normal use.