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.

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