d3d12: Shader image load/store support

I'm marching towards compute and ES3.1 support. It seems this isn't strictly a prereq for compute on ES3.1, but it is for compute on desktop GL, and since ES tests are hard to find on Windows... I figured let's go for it. This turns out to be kinda painful.

Then, several patches to our backend compiler. In theory, it already supports shader image load/store. In practice, the way they're done in CL and Vulkan is different enough from GL that some quirks need to be ironed out. Image atomics also hadn't been implemented yet, and the tests for this feature also exposed a missing early-z flag. Lastly, GL shaders don't use the scoped barriers that we get from SPIR-V (CL/Vulkan), so handle those.

Then, the gallium driver gets its turn. Lots of boilerplate tracking / translation, but some key points:

• Support for typed UAV loads for all GL-required formats is not a given, so we have to check for it. I'm not sure how broad support for this ends up being across the ecosystem. TBD if we could work around this, given the casting restrictions mentioned above.
• Cubemap UAVs aren't a thing in D3D, so we lower them to 2D arrays at a few points.
• The algorithm for translating memory barriers (global barriers) into D3D's per-resource barrier concept is sketchy at best, but does satisfy the host-memory-barrier piglit tests.
• Format casting requires that the resources be created with the TYPELESS variation of formats. Since we don't seem to get a PIPE_BIND_SHADER_IMAGE flag, this means that all UAV-capable resources get created with the ALLOW_UNORDERED_ACCESS flag and the TYPELESS format.
• The lowering pass for format casting is pretty gnarly, but does seem to work okay, at least for the stores that are tested by piglit.