HLSL: added support for tesselation shaders (WIP)

[Try]

Followup to #1739 - decided to start a new pr, since original is supper outdated now.
This is still more of a prototype at this point, and the goal of PR to collect opinions about approach.

Limitations:

• No support for barrier() - HLSL has no support for that in geometry pipeline at all. A exception will be thrown, if OpControlBarrier reached.
• Only gl_out[gl_InvocationID] is supported. This is actually inline with OpenGL, but limitation in comparation with Vulkan
• vertex.flip_vert_y is an issue. Flipping logically suppose to be done at the end of geometry pipeline.
• For HULL shader: patchconstantfunc will call tesc_main multiple times, only to determinate gl_TessLevel* values.
  This makes for ugly code, yet DX12 compiler is smart enough to remove this code.
  NOTE: there seems to be no way to pass extra data from main to patchconstantfunc - so we basically have to calculate gl_TessLevel* twice.
• No unit tests regarding HULL shaders - glslangValidator crashes on compiling. (DXC obviously works fine)

TODO:

• InputPath<> and OutputPatch<> sizes are hard-coded
• HULL shader, in DirectX, requires multiple extra annotations: outputcontrolpoints, domain, partitioning, outputtopology - those are absent from Tess-control shader in spirv. Hard-coded for now, long term idea is to fetch them from Tess-eval shader

Practical point of view:

• Hull shader is a performance concern
• Game engine that uses this cross-compilation has to do extra work to take care of vertex.flip_vert_y and to pass hints, like partitioning from TessEvaluation to Hull shader. What means - to delay cross compilation, until all shaders in pipeline are known.
• It works for my game: tested on water shader :)

[cdavis5e]

• No support for barrier() - HLSL has no support for that in geometry pipeline at all. A exception will be thrown, if OpControlBarrier reached.

My understanding is that D3D puts an implicit barrier between the various phases (control point, fork, join) of hull shader execution. OpenGL and Vulkan just make those barriers explicit. When we (i.e. in wined3d or vkd3d) translate a D3D hull shader to a GL/Vulkan tess. control shader, we have to insert these barriers ourselves. I think you actually might be able to get away with ignoring them, depending on how you break the shader into phases in HLSL.