Redundant `vkCmdBindPipeline` when the same pipeline is set twice

VulkanRenderPass.setPipeline assigns the incoming pipeline to its field and then records a bind, with nothing in between comparing it against what was already there, so consecutive draws sharing a pipeline each emit a command that changes nothing. GlRenderPass.setPipeline runs the same assignment behind a check that the incoming pipeline differs from the stored one, so a repeat costs only the comparison.

That check is the whole difference between the two paths. On the Vulkan side the bind also has to pick between the pipeline's two compiled variants, choosing the depth one or the depth-less one according to the render pass's own depth attachment state, which is fixed at construction and never changes afterwards, so a given pipeline always resolves to the same handle for the life of the pass and the repeated call cannot produce a different result. Nothing upstream filters the repeats either, since the frontend forwards every setPipeline call straight to the backend, and callers do repeat: the GUI renderer sets the pipeline once per element drawn, and consecutive elements usually share one.

Comparing against the currently bound pipeline before recording the bind, as the OpenGL path already does, would drop the repeats.