Detect and warn about uninitialized `i` index/counter variables in `for` loops

So this is related to this Mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=105755

Turns out that the Mesa compiler detects and throws warnings *when variables are potentially uninitialized* while the reference compiler does not. This is specially important to avoid undefined behavior and infinite loops that may completely lockup the system, specially because `glslangValidator` is used as the _de facto_ linter for GLSL.

```
$ bin/glslparsertest foo.frag pass 1.30
Successfully compiled fragment shader foo.frag: 0:54(14): warning: `i' used uninitialized
0:58(39): warning: `i' used uninitialized
0:59(53): warning: `i' used uninitialized
0:61(30): warning: `i' used uninitialized
0:62(33): warning: `i' used uninitialized
0:54(30): warning: `i' used uninitialized

PIGLIT: {"result": "pass" }
```
```
[swyter@osgiliath lnxbuildtest]$ glslangValidator -v foo.frag
Glslang Version: Overload400-PrecQual.2000 12-Apr-2017
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos.Overload400-PrecQual.2000 12-Apr-2017
GLSL Version: 4.60 glslang Khronos.Overload400-PrecQual.2000 12-Apr-2017
SPIR-V Version 0x00010000, Revision 12
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 3
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100
[swyter@osgiliath lnxbuildtest]$
```

Maybe this case should be handled better.

_PS_: Here is the test-case: [_uninitialized-for-loop-counter-variable-glsl-example.zip_](https://github.com/KhronosGroup/glslang/files/1851906/uninitialized-for-loop-counter-variable-glsl-example.zip)

Start by reproducing the attached uninitialized-for-loop-counter-variable-glsl-example.zip case with glslangValidator and compare it with the bin/glslparsertest output shown. Trace the compiler's handling of `for` loop counters and uninitialized-variable diagnostics; done means the case produces an appropriate warning without incorrectly rejecting the shader.

Written by the indexing model from the issue text.