DynamicUploader: fix pending serial race during WithUploadReservation

This change introduced a potential submit between ticks:
https://dawn-review.googlesource.com/c/dawn/+/226596

Specifically, WithUploadReservation would call
OnStagingMemoryFreePendingOnSubmit, which would call Queue::Submit when
enough memory was freed past some threshold. The problem is that in the
case of WriteTexture, WithUploadReservation gets called reentrantly,
once for the WriteTextureImpl, and once for the ClearTexture when
ensuring the texture is zero-initialized. If ever ClearTexture's
WithUploadReservation ends up submitting (because freed allocs >=
threshold), WriteTexture's copy command would be added to the command
list after the submit, but copying to a ring buffer reservation
associated with a serial for ClearTexture's submit (1) instead of the
one the Copy commands will be in (2).

For example, a possible scenario would be:

WriteTextureImpl
    WithUploadReservation
        Reservation suballoc allocated with PendingSerial 1
        Callback function called
            CopyFromStagingToTexture
                CopyFromStagingToTextureImpl
                    EnsureSubresourceContentInitialized
                        ClearTexture
                            WithUploadReservation
                                Reservation suballoc allocated with PendingSerial 1
                                Callback function called
                                OnStagingMemoryFreePendingOnSubmit
                                    Queue::Submit got serial 1 called because total freed allocs >= threshold
                                    PendingSerial now set to 2
                    RecordBufferTextureCopyWithBufferHandle
                        Copy is scheduled to suballoc with serial 1 _after_ submit for this serial

DeviceBase::Tick
    Queue::UpdateCompletedSerial
        CompletedSerial is set to 1
    DynamicUploader::Deallocate
        Reclaims ring buffer allocs with serial <= 1 (CompletedSerial)

The next WriteTexture allocs the reclaimed buffer alloc from the first
WriteTexture, while the copy command is still in flight on the GPU,
resulting in a GPU copy race to the same buffer.

The fix for this is to remove the submit call from
OnStagingMemoryFreePendingOnSubmit, and instead move it to function
MaybeSubmitPendingCommands which gets called in places where we can
guarantee that no reentrancy can occur; namely, at the end of
QueueBase::APIWriteBuffer, QueueBase::APIWriteTexture, and
BufferBase::APIUnmap.

Bug: 439492882
Change-Id: I84ea1273266c9d6f9d1d3bdb4d9fe5d9bfbc5ff8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/263636
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>