WIP: Implement composite specialization constants

[Qining]

Creating specialization constant aggregate variables with specialization
constants and OpSpecConstantComposite should has been already supported, issue #163.

Version/profile/semantics checking for the validity of using
specialization constants is not done yet.

Tests not added yet.

Approach:

1. Propagate 'SpecConstant' label in executeInitializer() to mark
   variable's initializer as 'SpecConstant' if it should be marked.

2. Handle contant variables with 'SpecConstant' initializer in
   executeInitializer(), propgate the 'SpecConstant' label to the variable
   and cache the initializer subtree.

3. Add function to create SpvConstants from initializer subtree. This
   may be able to replace the current SpvConstants creation routine which is using
   ConstantUnionArray.

Other:

1. Renamed the SpvConstants creation functions:
   createSpvSpecConstant => createSpvConstant
   createSpvConstant => createSpvConstantFromConstUnionArray

[Qining]

Example shader:

#version 450
layout(constant_id = 200) const float myfloat = 1.25;
layout(constant_id = 201) const int myint = 14;
struct structtype {
  float f;
  int i;
};
const structtype outer_struct_var = {myfloat, myint};
void main(){}

Generated SPIR-V code:

; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 1
; Bound: 12
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Vertex %4 "main"
               OpSource GLSL 450
               OpSourceExtension "GL_GOOGLE_cpp_style_line_directive"
               OpSourceExtension "GL_GOOGLE_include_directive"
               OpName %4 "main"
               OpName %10 "structtype"
               OpMemberName %10 0 "f"
               OpMemberName %10 1 "i"
               OpDecorate %7 SpecId 200
               OpDecorate %9 SpecId 201
          %2 = OpTypeVoid
          %3 = OpTypeFunction %2
          %6 = OpTypeFloat 32
          %7 = OpSpecConstant %6 1.25
          %8 = OpTypeInt 32 1
          %9 = OpSpecConstant %8 14
         %10 = OpTypeStruct %6 %8
         %11 = OpSpecConstantComposite %10 %7 %9
          %4 = OpFunction %2 None %3
          %5 = OpLabel
               OpReturn
               OpFunctionEnd

[Qining]

@dekimir @dneto0 @antiagainst @AWoloszyn @johnkslang PTAL.

const expr is not yet implemented.

[johnkslang]

Normally, the tree is built bottom up, and should be built with correct typing each step along the way.

E.g., When two nodes are combined with an operator (which becomes their parent), all the correct promotions and type setting of the result are done at that point in time. So, no multi-level tree should exist where the intermediate nodes don't already correctly reflect the combination of their children. Yet, this seems like a recursive "patch up" that implies a multi-level tree was built and left lying around for a while, while carrying incorrect information.

Maybe that works for this, I'm still thinking it through, just want to be clear what the typical pattern is, and see, is there a reason going against it is better?

[johnkslang]

The specification (KHR_vulkan_glsl) is also specific about what operations propagate "specialization constantness", so it makes sense to localize the propagation to where those operators are implemented. (That is, a general algorithm would accept too many things as being valid.)

[Qining]

Close as #211 replaces this CL.