See #1642

Also updates SPIRV-Tools and SPIRV-Headers known_good.

Fixes #1610

* Updated expected result due to version change

From internal Khronos discussions, work, and testing.

Update to newest SPIRV-Tools. It checks the Vulkan rule that all resources must have a set and binding decoration, which many tests fail. So add code to set a default value of zero. Also disable PCH for Ninja builds.

SPIR-V OpLines now contain filenames from HLSL-style #lines.

* Changed unit tests to only record known the validation pass/fail
status
 * errors are output as part of the failure message if the result is
 unexpected
 * can turn off validation for each test individually
* Moved some SPV_KHR_vulkan_memory_model tests to be compiled for Vulkan
1.1

Without this commit, if the XfbStride was explicitly set, the
decoration was added twice on the shader.

v2 (changes after Jonh Kessenich first review)
   * Simplified by just removing the firs assignment
   * Removed assert

This makes the rest of the AST consuming the result match GLSL
semantics and hence get complete type matching.

* Fixes use of optimizer
* Updated test outputs
 * GeometryStreams and TransformFeedback no longer fail validation

including SPV generation using SPV_EXT_fragment_invocation_density.
This is an alias of the functionality in SPV_NV_shading_rate, and thus in some
cases we can only have one set of the tokens present (switch statements), so
we have picked the EXT version. This required updating the expected test
results for SPV_NV_shading_rate.

Also updated the known-good for spirv-headers so that the validator in
spirv-tools knows about the new extension.

This change adds unary conversion folding when the source is a constant.
This fixes an ISV issue whereby:

```
const float16_t f = float16_t(42.0);
```

Wouldn't compile because the conversion operator would always produce an
EvqTemporary when it could have produced an EvqConst.

I've also added a test case that proves out that all basic-type to
basic-type conversions work.

Validator has more refined messages about what kind of block layout
rules have been applied.

Decomposes OpDot into corresponding multiplies and additions.

Missing check for float results in always emitting OpIMul even for float types

Adjusted a test not to use c register for
a structured buffer, they are supposed to
use t registers

Added comments with hints for what are the
register types are used for.

If a block has assigned a XfbOffset it is assumed that it would
inherit the current global XfbBuffer. This commit fixes two use cases:

1) Getting the members of a Block with a XfbOffset to be assigned an
   offset, as explained on GLSL 4.60 spec, section "4.4.2 Output
   Layout Qualifiers", subsection "Transform Feedback Layout
   Qualifiers".

2) Compute properly an error on overlapping ranges if a block is
   assigned a XfbOffset and one of it members is assigned a explicit
   one. This gets working because when the members of a block get
   assigned a Offset/Buffer at fixBlockXfbOffsets, then the block is
   deassigned the Offsets, so ranges are computed only with the block
   members.

BTW, this is already done when redeclaring block builtins.

Fixes #1535

Consider the following code:

    layout(constant_id=0) const int Y = 1;
    layout(constant_id=1) const int Z = 2;
    layout(constant_id=3) const int X = Y + Z;

Previously, it would produce SPIR-V decorations like this:

    Decorate 21(Y) SpecId 1
    Decorate 22 SpecId 3
    Decorate 33(Z) SpecId 0

This seems inaccurate, since the spec constant `X` that is dependent on
the two others did not get a name in the SPIR-V decorations. This behavior
may potentially negatively affect shader introspection capabilities.

This change alters the behavior to always add a name, which results in the code
above producing the following decorations:

    Decorate 21(Y) SpecId 1
    Decorate 22(X) SpecId 3
    Decorate 33(Z) SpecId 0

If the out variable is a struct type, with a xfb_offset explicitly
assigned, the members need to get their xfb_offset assigned. This is
specially relevant, as we cannot use layout qualifiers on struct
members.

UniformAndStorageBuffer8BitAccess capability.

When using the 8-bit storage extension it basically always used the
`UniformAndStorageBuffer8BitAccess` capability, even in cases where it
wasn't required. For instance if we are targeting Vulkan 1.1 (SPIR-V 1.3
or higher), and we are only using 8-bit types in an SSBO, we only need
the `StorageBuffer8BitAccess` capability.

I fixed this by enabling storage buffer use in Vulkan 1.1 / SPIR-V 1.3
or higher, and then changing the logic to match.

I also added some tests that will output different capabilities when run
on Vulkan 1.0 and 1.1, thus they are added twice to the test list (one
for each version).

Fixes #1539

- Emit relevant capability/extension for use of perprimitiveNV in fragment shader
- Remove redundant checks for mesh shader qualifiers in glslang.y
- Add profile version check for use of extension GL_NV_mesh_shader
- Add a new gtest for use of perprimitiveNV in fragment shader