Implement HXSL Syntax.code support

[Yanrishatum]

The proverbial footgun. Introduces Syntax.code to HXSL.

Rationale is that feature being primarily for rare cases where HXSL doesn't offer some very specific language feature (from recent examples - no access to GLSL GL_FragDepth), but user needs access to it. Being able to inject raw language code is much less work than having to somehow implement those features. Additionally it gives partial resolution to all those people in discord asking if they can just use raw GLSL/HLSL for their shaders.
Personal reasoning: I prefer giving the user options to shoot themselves in the foot if they so wish. If they want to do some weird stuff with shaders that HXSL can't do out of the box and likely will break - let them, it's their feet, not mine.

The implementation is somewhat volatile, but there's not much can be done about it, given how HXSL compilation process goes.

Syntax

Feature reserves the ECall(EField("Syntax", target)) expression access as attempt to inject raw code. Target can be code, hlsl or glsl respectively. The code target is language-independent variant and applied in both GLSL and HLSL outputs.
Additionally, due to how HXSL compilation process operates every argument have to be denoted with a meta of @r, @w or @rw, to specify how that variable going to be used.

Usage is similar to other Syntax.code implementations:
Syntax.code("{0} = someOp({1})", @w pixelColor, @r textureColor)

Implementation details

• Introduces new TSyntax typed expression.
• Syntax calls are always TVoid, and thus cannot be used to obtain some data directly. It may be possible to implement, however.
• TSyntax is considered to always have side effects.
• Checker: Converts Syntax. calls into TSyntax and verifies that arguments are valid (first arg should be const String, rest is optional arguments with access meta)
• Linker: Introduced hasSyntax flag to ShaderInfos, which is set when TSyntax is used. Processes read/write flags. When Syntax is used, shader is treated same as when isCompute or hasDiscard are set.
• DCE: Will link referenced vars based on read/write flags. All write variables are considered to depend on all read variables.
• Splitter: Processes read/write flags.
• Printer/Serializer: Properly supported

Notes

• It's currently possible to do Syntax.code("{0}", @rw (var1 + var2)), which would mark both var1/2 as write. I'm not sure if we should allow multiple TVar references per argument when write flag is set.
• Implementation could be simplified with removing closures if we add a check of "inSyntaxArg" when processing expressions in linker/dce/splitter. Current version is aimed to impact regular compilation step as little as possible, as it's expected that Syntax will be very rarely used.
• Syntax.code is not allowed at top-level, only inside methods, meaning it's impossible to manually add custom top-level code.
• Regardless of compile target all Syntax calls are processed. Thus Syntax.hlsl would still impact compilation even for GLSL. This is due to compiler not exactly being aware of which language it targets until the very last step.
• Syntax currently does not verify if code attempts to slot in argument that is outside of argument list.

[ncannasse]

I think SyntaxTarget should be a String, so adding more targets doesn't require to change HxSL AST

[Yanrishatum]

Done