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.

GLSL: Fix #1591: Require the id in subgroupBroadcast to be constant.

Update to newer SPIRV-Tools, including VK_EXT_scalar_block_layout

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

Merge branch 'scalar_block_layout' of https://github.com/jeffbolznv/glslang into jeffbolznv-scalar_block_layout

[HLSL/Spir-V] fix for incorrect spir-v on int dot(int, int)

Decomposes OpDot into corresponding multiplies and additions.

HLSL: implemented c register handling

HLSL: fix invalid spir-v vector * scalar for float1

Updated type conversion rules for HLSL frontend

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.

Handle potentially uninitialized result

PCH filename depends on current binary dir

Fixes #1572

Fix parser issue: redeclare gl_FragStencilRefARB is not supported

Apinheiro/xfb struct assignment

Add DeadBranchElim before MergeReturn in legalization.

MergeReturn now requires this or could throw an error.

Rename PCH macro to glslang_pch (to avoid name collision) and update to latest spirv-tools

Use precompiled headers for some glslang projects (MSVC-only)

Add names for composite spec constants in SPIR-V

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