Add fork documentation to README

I added https://github.com/aras-p/glsl-optimizer to our WebGL artwork pipeline recently, well aware that it's unmaintained.
I assumed that most of the features we'd depend on would be stable, and that the optimizer would catch trivial cases.
However, we have had at least 2 bugs introduced by glsl-opt + one crash; often times the optimizer doesn't do trivial optimizations or dead-code-elimination.

This seems to be one of the most heavily modified and active glsl-optimizer forks, so I gave it a shot.

Your fork seems to avoid at least some of these issues. We also get new errors and warnings which went unnoticed (even with shaders in production).

I'd like to switch our production artwork pipeline to your fork, but I'd like to see these questions answered in the README:

• Where is it used? (or where is https://github.com/jamienicol/glslopt-rs used?)
• Is it considered stable?
• Is it actively maintained (by single user, group or an organization?)
• What are planned changes / goals? (just mesa updates?)
• Will it remain usable as standalone tool or is focus on turning it into a lib? (we use glslopt directly, specifically for GLSL ES 1.00)
• Will there be tagged releases? (we are currently using the same version as the glslopt-rs submodule for published releases)
• Which other forks (or even separate optimizers) would you recommend for other use-cases?

If you want to attract more users I'd suggest to remove the fork-status of this project (because forks won't show up in the GitHub search).
You should also have your fork integrated in https://github.com/tgjones/shader-playground so people can experiment with it more easily.

@jamienicol I just realized that you aren't "watching" this repository; are you aware of this request?

[jamienicol]

@JannikGM I'm not sure why I wasn't watching, but I am now. Thanks for making me aware.

Yes we should update the readme, I just haven't found the time yet. I'll answer your questions here though:

• It is used in Firefox's rendering engine webrender
• We can't promise total stability but don't anticipate major changes
• It's maintained by me, but I wouldn't say actively. It works for Mozilla's needs already. Pull requests are welcome.
• Not even mesa updates are planned unless there's a need. Future changes could include adding support for new extensions/language features if-and-when Firefox requires them.
• The standalone binary will continue to exist in its current form.
• No tagged releases, master can be considered stable
• I'm afraid I don't know much about other forks: rebasing this on a newer Mesa version was our main requirement as it fixed several crashes and added support for required extensions. The other alternative I considered was compiling to SPIRV with glslang, then optimizing the SPIRV, then translating back to GLSL with SPIRV-cross. I don't believe that will work with GLSL ES 1.0, however.