automatic instanced rendering heuristic

[Aeva]

This builds off the work done on #232, as this solves many of the problems originally encountered in #195. See also: #197.

The criteria for automatic instancing might be this:

1. A large number of consecutive drawing calls without rebinding buffers or textures etc.
2. The only uniform properties that change in that time support instancing (#197).
3. The objects are all static: no visibility changing, dynamic sorting, or dynamic uniform values.

This could be further limited to only objects drawn via stamping, which ensures that we never need to de-instance anything.

Some tasks:

• [x] implement #197
• [x] buffer management
• [x] detecting the situation described above
• [x] generating instancing ir
• [x] add comments to generated code to denote instancing start/end
• [x] replace hardcoded _instctrl_world_matrix hack with automatic solution
• [x] refactor to remove state churn / consolidate bind code
• [x] make sure state change instancing teardown works
• [x] why is the lighting suddenly wrong in the demo?
• [ ] testing (instance multiple things, mixed with non-instanced things)
• [x] reuse instancing buffer for recompile events, if possible
• [x] a prettier demo

Fuzzy bits:

• appropriate instancing threshold? (maybe about 100?)
• capturing future stamp events after the renderer has been compiled once?

It looks like please.gl.vbo already has scaffolding for instancing and static code generation from an earlier effort, and can be used to track multiple arrays at once. Soooo, all that is really needed is to populate the arrays from static objects, and split matrices apart.

[Aeva]

This is complete enough to merge into fast_graph. Closing this ticket, will open a new one for making a more robust demo.