FramebufferVk::updateRenderPass reset the render pass description, but
not the framebuffer description.  This caused a disagreement between the
two regarding which attachments need to be unresolved.  Later,
FramebufferVk::startNewRenderPass could miscalculate whether a new
framebuffer needs to be generated based on changes in unresolve
attachments.

For example:

- say in the first render pass color needs to be unresolved.  Both RP
  and FB desc would remember this (each being keys for their respective
  caches).

- A following operation triggers syncState such that FB desc changes
  (for example rebind of attachment), which cleared RP desc but not FB
  desc's unresolve attachment state.

- If the next render pass does not require an unresolve (for example due
  to a clear or invalidate), then the framebuffer is not recreated
  because according to RP desc at the start and end of
  FramebufferVk::startNewRenderPass there has been no change in
  unresolve mask.
  * At start there's no unresolve because of syncState clearing it.
  * At end there's no unresolve because there's no need for unresolve.

- In the end, the framebuffer used for the first render pass would be
  used for the second render pass as well.  Note that:
  * The first render pass included an unresolve, i.e. two subpasses.
  * The second render pass requires one subpass according to its RP
    desc.

It's quite easy to accidentally have the framebuffer correctly recreated
(based on the reset RP desc) before FramebufferVk::startNewRenderPass.
Note that since syncState has called updateRenderPass, FB desc has
necessarily changed, and mFramebuffer is nullptr, so any call to
FramebufferVk::getFramebuffer would recreate the framebuffer.
Both clear and invalidate call FramebufferVk::getFramebuffer.

The issue is reproducible in situations where clear/invalidate has been
called before the framebuffer is modified, and then draw is issued after
the modification.  An ASSERT is added to catch discrepencies between RP
desc and FB desc to catch bugs even when the issue doesn't manifest
itself as a VVL error.

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