Guard loadRecord, deleteRecord, and saveRecord behind AsyncLocks

[alecgrieser]

This introduces a new StoreConcurrencyManager interface. This is designed to help the FDBRecordStore manage its intra-transaction operations. For the moment, that means making sure that reads and writes to the same individual records do not interfere, though we can increase the level of protection in the future by adding things like additional levels of locking. For example, we could add a second lock that is shared by all multi-record operations, and then each operation needs to grab a shared or exclusive lock depending on what the operation is. However, we do need to a be a little careful there to avoid deadlocks, as our locking framework is not currently re-entrant.

Note that we already had an AsyncLock framework, so the work in this PR is really just to:

1. Create an abstraction for managing the locks needed by the FDBRecordStore.
2. Update the relevant methods in the store to use the new lock manager.
3. Add tests to make sure the lock management works. This includes a new stress test which interleaves operations across the store and ensures that we wind up in a consistent state.

This also introduces a no-op implementation. By default, FDBRecordStores opt in to the new behavior. That's a little bit unorthodox, but given that this is a safety feature, it seems like a good idea to op people in to the safe behavior, and then they can escape back to the old behavior if they really need to.

Caution: There was one place where enabling this was found to have an issue, and it's in the SlidingWindowIndexMaintainer. That index maintainer (uniquely) can read a record as part of its maintenance. This means that we can end up in a deadlock, if there are two concurrent saves, and one of them is to the record that is currently the boundary between in-the-window and out-of-the-window. Users of sliding window indexes may therefore need to disable this feature until it can be made more robust.

This resolves #4522