Resizing details / underspecification

The section on resizing is underspecified. Some questions that come to mind:

• If agent A calls grow_memory, and lets agent B know that it has done so by writing something into shared memory (maybe racily), can agent B when it sees that write then assume that it can access memory up to the new limit, or must agent B do something special (eg call current_memory) before it can observe the new size?

• Ditto, can agent B access memory up to the new limit without synchronizing in any way with agent A?

• Is agent A's growing of the memory reflected in the length fields of the SABs in all the agents? If so, is reading that length field an atomically ordered operation? Otherwise, is there a way to obtain new SABs that reflect that length?

• When agent A and agent B both call grow_memory at the same time with non-equal arguments, what happens? Cumulative growth seems most reasonable.

@jfbastien also noted that ES2017 algorithms for atomics may or may not be correct if the SAB length or the buffer's length can be updated in the middle of an operation, and more generally also pointed out that even if no implementations will implement growable SABs by moving the memory, we need to spell out what happens if a resize races with a read or a write (or we need to spec "as if memory is never moved" for the MVP, which seems OK).

Start with the resizing questions in this issue and the linked TC39 issue 129. Work through the required semantics for concurrent growth, shared-buffer lengths, memory access, and races, then document a resolved specification direction; no implementation files or tests are named in the payload.