Imagine the following scenario:

1. Clear draw framebuffer
2. Invalidate draw framebuffer
3. Copy from read framebuffer into texture that is attached to draw
   framebuffer
4. Draw again into draw framebuffer

At step 2, FramebufferVk::syncState is called which extracts the clear
and stores it in mDeferredClears, but since the framebuffer description
hasn't changed, a new render pass is not started.

At step 3, the texture attached to the draw framebuffer is used as copy
destination, but its clear which is stored in the (apparently
irrelevant) draw framebuffer is not flushed.

At step 4, a new render pass is started which clears the draw
framebuffer, trampling the copy in step 3.

This change makes sure invalidate results in a flushDeferredClears().
With glInvalidateFramebuffer() (not glInvalidateSubFramebuffer()), the
deferred clears for invalidated framebuffers are discarded first.

It is unknown whether there are similar situations where syncState
gathers deferred clears, but they are not flushed before the attachments
are updated outside the framebuffer.  To catch similar bugs in the
future, assertions are added to FramebufferVk::syncState such that if a
dirty bit is set for the contents of an attachment, we can make sure
there are no prior deferred clears stored for that attachment.

Bug: angleproject:4862
Change-Id: Idb1a08b53e7f011f0fc9a54d478289030b6d77a8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2308034Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>