Please provide a better path for glslang contributors

There are currently many outstanding issues for feature requests for GLSL, and during the Vulkanize event, many people were curious about the status of such features. It was brought up that khronos doesn't have the bandwidth right now to spend a lot of time on this. However many of us *could* in theory aid with pull requests to this repo our selves, or otherwise aid in developing these features.

This however is not an easy task, it is not only hard to navigate the codebase, it's very difficult to understand. It speaks to the difficulty of working with the glslang codebase that many of such features *have been implemented in compilers the transpile to GLSL from a superset of GLSL* (including templates!) instead of extensions to glslang. I myself have opted to write transpilers instead of extending glslang when trying to add my own features because of just how difficult it is to understand where to even find *where* I'd add something.

A comment made in the Vulkan Discord talks about this difficulty and where it lies here:

> I'm not honestly sure you need to refactor code as much as explain where exactly I would change things to make new feature adjustments. It's basically impossible to know what effects what in that repo. Even something as simple as adding a new built-in, where would I even do that? I'd expect a simple "a file with a set of built ins processed, and SPIR-V mapped to those names", but that doesn't appear to be the case. There needs to be something more a long the lines of an architectural overview, some high level thing that tells people exactly where things exist, and where you would make changes to add features, and proper documentation of the code explaining things

Some sort of architectural overview, that shows *where exactly certain language processing takes place* would be really nice. where AST parsing takes place, semantic analysis, tokenization etc... (though I know some of this is in a separate parser generator [bison]? How to modify that for use in GLSL would also be good information) Information like "pitfalls", dos and don'ts top level comments per file helping understand the general idea of what each section does.

For example, how do I navigate the codebase as a completely new developer? Some of this information exists in the *very bottom* of the page here https://github.com/KhronosGroup/glslang#basic-internal-operation but it doesn't give near enough information to start actual substantive development. Heck it doesn't even answer questions like "Where does the compiler infrastructure even live?", or "What is inside all the top level directories?" As I go down in the glslang folder, I'm met with more questions most of the files I'm looking at don't have top level comments explaining exactly the purpose of the file that's there, the only comment is the liscense at the top. There are some comments inline with code, but they all assume that you understand the context of what is going on in the first place. Some of these files do have top level comments, but the information is important enough to be available *outside* the header as a part of a much wider context, such as in [glslang/MachineIndependent/SymbolTable.h](https://github.com/KhronosGroup/glslang/blob/master/glslang/MachineIndependent/SymbolTable.h), and it still doesn't explain *how* the code is accomplishing the above tasks in the header documentation.

It would be extremely helpful to have examples of (maybe in separate example repos) of how extend glsl, for example:

* How to change the grammar
* How to add a keyword
* How to add a built-in function
* How to add a new type
* How to add a an operator
* How to add a new statement type
* How to reconcile these new features with the reflection capabilities of glslang.

Along similar lines It would also be helpful to have a sort of walkthrough of how your GLSL text goes through glslang, where each part of the text touches, when and why.

These things *should be straight forward* for the maintainers to demonstrate, as these things have *already* had to happen to even have glslang exist in the first place. Some sort of text instruction similar to the style of [Kelidiscope](https://llvm.org/docs/tutorial/) would be great

Start with the README's “Basic internal operation” section, the top-level glslang directories, and glslang/MachineIndependent/SymbolTable.h. Trace the parser-generation path, tokenization, AST, semantic analysis, built-ins, and SPIR-V generation, then document those entry points and feature-extension workflows. Done means a newcomer can locate each stage and understand how to add the requested language features.

Written by the indexing model from the issue text.