Mismatch in GLSL/Vulkan behavior for gl_FragDepth

As of the 1.3.210 Vulkan spec update, Vulkan clarified that not writing to the FragDepth built-in is undefined behavior - undefined values can lead to undefined behavior, so the difference is _somewhat_ moot.

However, GLSL states:

> If a shader statically assigns a value to gl_FragDepth,
> and there is an execution path through the shader that does not set gl_FragDepth, then the value of
> the fragment’s depth may be undefined for executions of the shader that take that path. That is, if
> the set of linked fragment shaders statically contain a write to gl_FragDepth, then it is responsible
> for always writing it.

Which seems to intend that there's no potential for crashes.

In order to reconcile this, GLSLang should initialise the value of gl_FragDepth any time gl_FragDepth is declared, when generating SPIR-V. Initializing it to gl_FragCoord.z is likely the safest choice, as this is most likely what developers intend when writing such code.

Start by tracing glslang's GLSL-to-SPIR-V handling for declared gl_FragDepth and compare it with the GLSL and Vulkan behavior described here. Done means generated SPIR-V initializes gl_FragDepth to gl_FragCoord.z whenever it is declared, with coverage for execution paths that otherwise omit a write.

Written by the indexing model from the issue text.