These tests previously encountered errors attempting to transfer images
from VK_QUEUE_FAMILY_EXTERNAL back to itself (this is not valid because
one of the queues families in a memory barrier must be the family of the
queue that executes the barrier). These invalid transfers were made
because our ownership tracking started all resources in the "externally
owned" state, with the expectation that the first operation on the
resource would be a call to glWaitSemaphoreEXT to acquire ownership.

It is far from clear that a call to glWaitSemaphoreEXT is always
required to gain ownership of a resource. The EXT_external_objects
extension inherits Vulkan's semantics, and what the Vulkan spec says is
that the first entity to access a resource implicitly assumes ownership
(see 11.7.1 "External Resource Sharing"). Binding a resource to memory
does not constitute an access to that resource, or affect its ownership.
Allocations should not be accesses, either; they happen at a lower level
and the entire discussion about determining initial ownership from first
access would serve no purpose if the mere allocation of the underlying
memory was sufficient to assume ownership.

This patch therefore adjusts the initial queue family ownership of
resources created in memory objects to be the ANGLE renderer's queue
family, just like a locally allocated image would be. Since this
ownership state may not be correct (an external API may have already
accessed the image, and assumed ownership) we must relax our assertions
to allow a call to glWaitSemaphoreEXT while in this state. For images,
this is only permitted while the layout is undefined.

An alternative would be to set the initial queue family to a sentinel
value that indicates that we don't know, but that would require checking
for this value before making any accesses, and only then asserting local
ownership. There's no real upside to this; the net effect of the first
access rule is that we must effectively assume ownership until proven
otherwise.

Besides appearing to be the spec's intent, this change simplifies some
usage scenarios because a queue submission is not required in the source
Vulkan instance in order to allocate resources that will be initially
accessed from GL. This seems especially important since there's no
mechanism to allocate an external memory object from inside GL.

The only downside is that the initial ambiguity in ownership prevents us
from diagnosing certain errors, but this limitation is temporary;
ownership becomes clear as soon as there is at least one access or at
least one synchronization operation affecting the resource.

Bug: angleproject:4229
Change-Id: Ibca2bfe373810c55352b1d849d07733d5fcfe5f4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2178946
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>