WebGL 2 support considerations

[Aeva]

Reflecting on benchmark results for a stress test in fast_graph, a step before jumping right into instancing for static objects (#246) could be to use uniform buffer objects. Problem is, those are only available in WebGL 2.

I was hoping that M.GRL could try to acquire a WebGL 2 context first, and then fall back to WebGL 1 if needed, and have the engine treat any new functionality as being optional, as it does with most webgl 1 extensions.

For better or for worse, the shader language received a number of changes that would require(?) support for. I've been fantasizing about throwing together a scheme-like shader language to use instead of GLSL for m.grl to compile to GLSL. An advantage to this might be that the shader compiler could be simplified greatly, but also to not favor any specific compiler target.

So, a rough list of things to do for this:

• a more flexible input shader language supporting multiple compilation targets
• update the webgl context bootstrapping code
• book keeping for if new features are present (might just be a global for the webgl version)
• update static object codegen to use UBOs?

[Aeva]

Commit 1fdbcf9c8c405dc5435cf56f0ac505a496621a6d (glsl_cleanup branch) adds a version macro to the glsl compiler output, so once #261 lands, this probably removes the main blocker to upgrading to WebGL2!