If there are clears prior to a glClear() call, those clears were
flushed (starting a new render pass) and then the clear call's clears
would be applied (essentially modifying the loadOps of said render
pass).

The main downside of the above is that the current glClear() clears
don't get a chance to be deferred.  This was observed in Chrome which
clears an attachment with an emulated format, then switches
framebuffers.

Additionally, if the render pass had already been started, the deferred
clears could have become inlined instead of breaking the render pass.
Although, it's unlikely for there to be deferred clears when the render
pass is already open.

This change first identifies which clears need to go through the draw
path (scissored, masked or as workaround for driver bug).  It merges the
rest of the clears (that don't need the draw path) with the deferred
clears.  It then checks deferred clears and applies them by either:

- vkCmdClearAttachments if mid RP
- Start a new render pass and use loadOps, if any draw-based clear needs
  to follow.
- Modify current RP loadOps / defer the clear

Afterwards, the draw-based clears are applied.

Bug: angleproject:4836
Change-Id: Id4992c78983b199734508c9d4bb18ed3195c91ec
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2455167
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>