Previous to this change, glMemoryBarrier was processed as it is issued.
This made it impossible to know whether a draw call would follow or a
dispatch call, and what resources it would use.  The render pass was
conservatively broken due to this limitation.  To address this
limitation, handling of glMemoryBarrier is deferred until the next
draw or dispatch call.

Note that glMemoryBarrier acts as two barriers:

- An execution+memory barrier: shader writes are made visible to
  subsequent accesses
- Another execution barrier: shader accesses are finished before
  subsequent writes

An important observation is that for most resources, ANGLE actually
necessarily has to issue memory barriers automatically to conform with
Vulkan.  In terms of memory barrier thus, ANGLE already does the right
thing except for when there's no binding change.  This means WaW hazards
(i.e. storage buffer and image writes) with no binding change require a
memory barrier as a result of glMemoryBarrier.  In all other cases, it's
enough for glMemoryBarrier to break the render pass if necessary and
ensure that corresponding bindings are marked dirty (for the execution
or memory barriers to happen automatically later).

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