The exported memory/sync handles don't really make sense if we don't
expose the device UUID they belong to. This is a cross-API concept.

This change introduces the generic definition of an exported semaphore
pair. Such a pair can be imported by an external API for signalling and
waiting, and will be passable to _hold() and _release() methods once
those get introduced.

Semaphores for internal use should just be created directly.

When we introduce exportable semaphores, we'll have handles which are
not memory-backed. To avoid a sloppy API, let's explicitly separate the
two ideas. This also presents an opportunity to pull the object offset
within the memory into the mem_handle definition. We also refactor the
way the handle caps are presented to the user, to allow distinguishing
between caps for shared memory and those for semaphores.

We also turn the struct pl_gpu_handle into a union, since in practice,
it is not going to be useful to export a given resource as multiple
types of external handle - it will just one or another type. (This is
mostly a simple substitution, but we must also note that vk_slabs must
also carry the handle type explicitly, as we can no longer look at which
field(s) are set in a pl_gpu_handle.)

This is obviously an API break for any external usage of buffers or
textures.

This makes no real sense in gpu.h, since the pl_gpu doesn't actually
need this information in any way. It's only needed for the shader header
generation inside dispatch.h, so having it in shaders.h is the right
place.

Makes some code arguably a bit uglier, but whatever.

Ever since SPIRV-Cross has started emulating std140 layout when
cross-compiling SPIR-V to D3D11, there's no more real justification for
us to make this dependent on the backend type.

In theory, metal could require something different here - but even then
we should work around it in SPIRV-Cross rather than trying to make our
code depend on it at runtime.

There's really no need to require this

This is useful to share memory with e.g. CUDA or other external APIs.

Closes #43

Most of the time this layout is not actually needed.

This reverts commit b6104e12.

No idea why this was not the case before. It's super useful.

Much like glFinish, this can be useful when you want to force all GPU
work to be completed (for any number of reasons, e.g. deinit logic or
for benchmarking purposes).

Since we no longer need the GCC pragma for symbol visibility, there's
also no more reason to have common.h import everything under the sun -
so only have modules import what they actually use.

This speeds up compilation a tiny bit.

This required some pretty complicated logic, but I tested it and it
seems to be working. Basically, we can now just directly upload e.g.
rgb8 by treating it as rgba8. This is a gigantic hack, but it's much
faster than trying to CPU-convert it in cases where the data is already
readily available in packed form, e.g. in a mapped buffer.

Closes #9

If all 8 buffers are in use, just block for availability

This is a very major rewrite operation, but all of the actual logic is
unaffected. The change is completely cosmetic.

The idea behind this is to avoid clashing the mpv ra_ namespace when
libplacebo eventually makes its way back into mpv, allowing it to
coexist with vo_gpu peacefully (at least for the transition period).

It's also sort of weirdly inconsistent with the rest of libplacebo
anyway.