anv: Implement VK_KHR_draw_indirect_count and VK_EXT_conditional_rendering

This implements VK_KHR_draw_indirect_count for gen7+ and VK_EXT_conditional_rendering for gen8+, they are together because most of VK_EXT_conditional_rendering complexity is interaction with function from VK_KHR_draw_indirect_count.

It passed CI: https://mesa-ci.01.org/mesa_custom/builds/4530/group/63a9f0ea7bb98050796b649e85481845 (all failures were on Haswell).

In mailing lists @jekstrand asked if it's valid to copy from alu register to MI_PREDICATE_RESULT, like this: emit_lrr(&cmd_buffer->batch, MI_PREDICATE_RESULT, CS_GPR(MI_ALU_REG15));

From what I have found:

In specs MI_PREDICATE_RESULT has next description:

MI_PREDICATE_RESULT Register Space: MMIO: 0/2/0 Source: RenderCS Default Value: 0x00000000 Access: R/W Size (in bits): 32

This bit is the result of the last MI_PREDICATE.

And also it is listed in "User Mode Non-Privileged Registers for Render Command Streamer (RCS)" table.

So saving and restoring MI_PREDICATE_RESULT looks like a valid and correct operation, also it works on tested hardware.

Haswell: For now I excluded Haswell since it fails to pass any test even though from specifications it should not differ from newer architectures in relevant areas, in short it's impossible to manually set MI_PREDICATE_RESULT (by copying from alu register and by direct load) and even copying it to other register corrupts MI_PREDICATE_RESULT, e.g.:

`emit_lrr(&cmd_buffer->batch, CS_GPR(MI_ALU_REG1), MI_PREDICATE_RESULT);` corrupts `MI_PREDICATE_RESULT` (only on Haswell) The details of why are still unknown. As an alternative for Haswell we can always emit MI_PREDICATE after MI_PREDICATE_RESULT is changed in functions of `VK_KHR_draw_indirect_count` but I want to at least land existing functionality and then find out what's wrong with Haswell.