fix: Support sharing cached Pipelines with different parameters/topology in WebGL

[ibgreen]

For discussion.

Background

• Make sure we don't create more copies of a Program in WebGL than we need. Before this PR, we create one pipeline for every parameter configuration (just as we must in WebGPU).

Change List

• Renderpipeline.draw() now accepts optional parameters and topology.
• These are ignored on WebGPU but on WebGL these are used instead of RenderPipeline.parameters/topology if provided.
• PipelineFactor no longer includes topology and parameters in hash on WebGL

Notes

• 4 parameters can be changed in WebGPU should they be handled by this mechanism in parallel with existing mechanism?

Commentary

There is a balance between completely pushing this type of logic down into core and keeping core as a thin GPU API mapping layer.

I have given this quite a bit of thought. By handling some small amounts of device differences like this in the Model, we can keep the complexity of the @luma.gl/core module low and we still hide WebGL/WebGPU differences from applications.

There are a few other differences such as constant attributes and TransformFeedback that that are also handled this way. I feel that this is a good balance, better than the alternatives.

[Pessimistress]

Not part of this PR, but should we move the hash logic to each device?

device.getRenderPipelineHash(props: RenderpipelineProps): string

[ibgreen]

Yes... Perhaps we could just expose the capabilities instead, perhaps using the device feature system: dynamic-topology-webgl, dynamic-parameters-webgl so that the PipelineFactory could take those into account without switching on device type, and the factory could still own and encapsulate the hashing system.