Mesh-Program attribute matching on bind

[kvark]

This PR implements actual shader-mesh binding by matching names. This can be cached (as the next step) with a simple HashMap that holds the sequence of attribute indices, but I'd rather have all other matching functionality done first (shader parameters is the major one, and there is also a need to match shader outputs).

I had to put a simple handle management in place, to be replaced by a proper one with #22.

[brendanzab]

How far are we off being able to have an example for this?

[brendanzab]

Looks good! Thoughts @csherratt?

[kvark]

@bjz an example? Sorry if I'm stating the obvious but this code is active already. It's matching mesh data vs shader inputs on every draw call, including the one we do for the triangle. That sample has only one attribute used, so it is a slightly redundant case... but still a case ;)

If you just want a bigger example, then the terrain one will suffice. I think we need #19 badly before implementing it.

[ghost]

The change as a whole looks good, I think it is ok to merge.

[brendanzab]

@kvark Awesome, sounds good

[kvark]

@csherratt I'm not sure what would be the best way to deal with unrecognized attributes or uniforms.

On the one hand, it's not fatal to the execution. We can either ignore binding the attribute/uniform (possibly by simply not registering it on our side), or mark the whole shader program as invalid (preventing all the draw calls with it). Either an error!, or some real error passed back by the async channel would tell the user what went wrong.

On the other hand, I struggle to see the use case where this error happens on a non-developer machine. And the developer (of the shader) should fix it right away.