From vkCmdBindPipeline spec:

  "pipelineBindPoint is a VkPipelineBindPoint value specifying to
   which bind point the pipeline is bound. Binding one does not disturb
   the others."

But internally we were only handling one pipeline per command buffer,
so binding a pipeline of one type would override an alredy bound
pipeline of other type.

Note that for push constants, in the same way that we were keeping one
client array and one bo for the values, for all stages, independently
of the stageFlags specified by vkCmdPushConstants, we are keeping the
same idea here, so such client array and bo is still tied to the
command buffer, and used by the two pipeline bind points. That makes
far easier tracking the push constants. We could revisit in the future
if we want a more fine grained tracking.

Fixes the following crashes:
 dEQP-VK.pipeline.push_constant.lifetime.pipeline_change_diff_range_bind_push_vert_and_comp
 dEQP-VK.pipeline.push_constant.lifetime.pipeline_change_same_range_bind_push_vert_and_comp

v2 (from Iago review)
   * Move removal of v3dv_resource definition to a different commit.
   * Use the new v3dv_cmd_pipeline_state on the cmd buffer meta
     sub-struct, call it gfx for consistency

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <!8613>