Add validation of push constants in pipeline creation and command encoding

[yanchith]

Is your feature request related to a problem? Please describe.

I erroneously managed to have the following setup in wgpu 0.13.1:

• wgpu::RenderPipeline defines no push constant ranges
• the shader expects push constants
• there are no push constants sent with RenderPass::set_push_constants

Vulkan validation layers correctly caught something is amiss, but wgpu validation did not.

[  1.524595][ERROR][wgpu_hal::vulkan::instance] VALIDATION [VUID-vkCmdDraw-maintenance4-06425 (0x63512146)]
        Validation Error: [ VUID-vkCmdDraw-maintenance4-06425 ] Object 0: handle = 0x2387196fad0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x9f9b41000000003c, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; Object 2: handle = 0x56c9bd0000000040, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x635121
46 | vkCmdDraw(): Shader in VK_SHADER_STAGE_VERTEX_BIT uses push-constant statically but vkCmdPushConstants was not called yet for pipeline layout VkPipelineLayout 0x9f9b41000000003c[]. The Vulkan spec states: If the maintenance4 feature is not enabled, then for each push constant that is statically used b
y the VkPipeline bound to the pipeline bind point used by this command, a push constant value must have been set for the same pipeline bind point, with a VkPipelineLayout that is compatible for push constants, with the VkPipelineLayout used to create the current VkPipeline, as described in Pipeline Layout
Compatibility (https://vulkan.lunarg.com/doc/view/1.3.204.1/windows/1.3-extensions/vkspec.html#VUID-vkCmdDraw-maintenance4-06425)

Describe the solution you'd like

I'd expect the following:

• A validation of this in wgpu for pipeline creation: the render pipeline and the shader were not compatible.
• A validation of this in wgpu for render pass encoding: the render pipeline thought it needs push constants, probably because the shader was authoritative over the pipeline definition in Rust code, but there were no push constants encoded.

Describe alternatives you've considered

N/A

Additional context

N/A

[cwfitzgerald]

Closing in favor of #3133