Kernel extensions

TODO: possible additional arguments to graphics.defineEffect and their motivation, constraints, etc.

TODO: some ways to interact with already-loaded shaders, e.g.

• replace the source (non-binary shaders)
• dummy it out ("removing" the shader)
• updating uniforms array if available

Elaborate what all of the above needs to observe. The source-affecting options are mainly throwing a bone to shader editors, so maybe these should be opt-in only... would it make sense to invalidate other options such as category, time dependence, etc.? (I'm thinking any such shader is potentially already making use of the configuration in question, so this would pull the rug out from under it; whereas with the source alone there's less danger.)

---

Rough outline of other fields in kernel declaration:

timeTransform = "sin", timeArg1 = 5, timeArg2 = 3,

for CoronaTotalTime stuff,

wantsUniformVectors = true, resolveUniformVectorCount = true,

for uniform arrays,

isEditable = true,

for shaders that can be rewritten,

fillSamplerType1 = "cubemap", fillSamplerType2 = "volume",

for sampler types,

fragmentRequires = { requires = "other", snippet = [[blah]] }, vertexRequires = { --[[ ditto ]] },

for incorporating pre-registered snippets (ideally with redundancy checks and topological sorting),

onActivate = Begin, onDeactivate = End,

for pre- and post-binding logic. (These would more or less have to be command-like because of when they happen, so probably following some policies such as described here.)

Some instancing stuff would go here too. Anything else?

(Compute kernels might be a parallel but similar thing?)

Most of these would produce a "shader state" object that can be used to effect these operations, obtainable from some graphics API for example.

---

Priority-wise, this is mixed, but I think at the moment everything is related to another idea anyhow.