Take the following scenario:

  1. glClear
  2. glScissor(half of framebuffer)
  3. glDrawArrays

The clear in step 1 is deferred.  When FramebufferVk::syncState is
called in step 3, the deferred clear was applied using
vkCmdClearColorImage because the draw call is scissored.  This causes
loadOp=LOAD to be used after the clear because the render pass is
started too small (the same size as the scissor).

This change makes scissored operations also take advantage of
loadOp=LOAD with deferred clears.  A number of changes are made to this
effect:

- FramebufferVk::syncState no longer limits collecting deferred clears
  to no-scissor.
- FramebufferVk::startNewRenderPass automatically expands the render
  area to full size if it's clearing any attachment.
- A number of bugs are fixed where FramebufferVk::flushDeferredClears is
  called with the scissor area.  Instead, flushDeferredClears now
  unconditionally uses the complete render area.  Note that these bugs
  didn't have symptoms as "scissor" and "deferred clears" were mutually
  exclusive.

Bug: angleproject:4988
Change-Id: I24fc3d88bf9c8998869b36c863692d0f0acce994
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511371Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>