Fixed #787: IndigoShader, expose ability to add UniformBlocks

[davesmith00000]

No description provided.

[davesmith00000]

This works, but I'm still thinking about what I've ended up doing here a bit.

I've realised (as a consequence of this work, wasn't the point of the PR) that you can now use one case class to define the data structure for both the Indigo and Ultraviolet side of passing data from engine to shader. The catch is that your definition must eventually use the few UV types we support for UBOs.

This means that either we allow all the types we can support (as-is, such as Radians) but the user has to know they need two different case classes (class 1 has angle: Radians and class 2 angle: Float), or we reduce support down to the 5 acceptable types and they get an error... but at least it's obvious when there's a problem.

I'm leaning towards the latter with some extension methods to aide conversion.

[davesmith00000]

Will be the first and only implicit conversion in Indigo. 😛

Based on the comment above uniformBlocks below, saves the user from doing:

final case class CustomData(color: RGBA, customTime: Seconds) extends FragmentEnvReference derives ToUniformBlock
def uniformBlocks: Batch[UniformBlock] = Batch(
  summon[ToUniformBlock[CustomData]].toUniformBlock(CustomData(RGBA.Magenta, 0.seconds))
)

[davesmith00000]

I'm leaning towards the latter with some extension methods to aide conversion.

I've had a go and the implementation sucks and is quite spectacularly unfriendly to use. I think I'm going to keep it as-is and just recommend sticking with UV types in the examples.