span: deadlocks are theoretically possible with the concurrentFrontier

While the `btreeFrontier` will return an error when attempting to write to the frontier while iterating over it, the concurrent frontier will instead deadlock.

We could consider extracting the logic from the `btreeFrontier` into the `concurrentFrontier` and note that it isn't safe for concurrent use.

We might also want to use an `sync.RWMutex` (instead of an `atomic.Bool`) and use `TryAcquire` to determine if we need to return errors. Although, this isn't necessary if we choose to disallow multiple readers.

Example reproduction:
```
func TestConcurrentFrontierIterationAndForward(t *testing.T) {
defer leaktest.AfterTest(t)()

// Create a concurrent frontier with multiple spans.
spans := []roachpb.Span{
makeSpan("a", "b"),
makeSpan("c", "d"),
makeSpan("e", "f"),
}
innerFrontier, err := MakeFrontier(spans...)
require.NoError(t, err)
f := MakeConcurrentFrontier(innerFrontier)

// Iterate over frontier while attempting to Forward.
for span, ts := range f.Entries() {
// This call will deadlock.
_, err := f.Forward(span, hlc.Timestamp{WallTime: ts.WallTime + 1})
require.NoError(t, err)
}
}
```

Related to #151219

Jira issue: CRDB-53122