layers: NV per-viewport array count VUs

[Wint3rNight]

Four VUs require an NV per-viewport array to be at least as large as the
viewport count. Only the viewport swizzle one was implemented that way, so this
started as adding the missing draw time checks and turned up three bugs in the
pipeline creation ones along the way.

Fixing the pipeline creation VUs

VU	Spec	Was implemented as
01215 swizzle	nv >= viewportCount	nv < viewportCount — correct
01726 W-scaling	nv >= viewportCount	nv != viewportCount
02029 exclusive scissor	nv == 0 || nv >= viewportCount	nv != 0 && nv != viewportCount
02056 shading rate image	nv >= viewportCount	nv > viewportCount

All three rejected valid pipelines. 02056 is the worst of them: it was inverted,
so it also never caught the case the VU actually describes.

Three existing tests asserted the old behaviour and are updated. Since that
removed the only coverage of a real 02029 violation, a negative test is added
for it.

Adding the draw time VUs

With VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT the viewport count is only known at
draw time, so the pipeline's static NV arrays have to be checked against it. The
dynamic side of each of these was already validated, the static side was not.

• VUID-vkCmdDraw-viewportCount-04137 — VkPipelineViewportWScalingStateCreateInfoNV
• VUID-vkCmdDraw-viewportCount-04139 — VkPipelineViewportShadingRateImageStateCreateInfoNV
• VUID-vkCmdDraw-viewportCount-07492 — VkPipelineViewportSwizzleStateCreateInfoNV
• VUID-vkCmdDraw-VkPipelineVieportCreateInfo-04142 — VkPipelineViewportExclusiveScissorStateCreateInfoNV

Setting more viewports than the array holds means the implementation indexes
past the end of it, and nothing else reports that.

vk_validation_stats goes from 3520 to 3416 unimplemented, which is these four
across the 26 action commands, with nothing newly uncovered.

Question on 04141

I left VUID-vkCmdDraw-VkPipelineVieportCreateInfo-04141 unimplemented. It
compares against the same VkPipelineViewportSwizzleStateCreateInfoNV::viewportCount
as 07492 and only differs in how the condition is worded, so it looks like the
older form from before the swizzle state could be dynamic. Happy to emit it
alongside 07492, or add it to unimplementable_validation.h next to the other
redundant VUID variants, whichever you prefer.

Testing

• 4 negative tests for the new VUs, 3 positive tests for the fixed ones, plus
  the new 02029 negative test
• Reverting sl_pipeline.cpp fails all 3 positive tests, reverting
  cc_cmd_buffer_dynamic.cpp fails all 4 negative tests
• 678 tests pass across NegativeDynamicState, PositiveDynamicState,
  NegativePipeline, PositivePipeline, NegativeCommand,
  NegativeFragmentShadingRate, NegativeShaderObject, PositiveShaderObject
  and NegativeViewportInheritance, with no failures
• check_code_format.py passes, clang-format 22.1.8

Two things I could not check locally. The full suite does not finish here, it
crashes in PositiveDescriptorHeapUntyped.BufferAsFunctionParameter, and it
does that on an unmodified checkout too, so it is unrelated to this change but
it does mean I ran the suites above rather than everything.
NegativeFragmentShadingRate.ShadingRateImageNV also skips on my device, though
ShadingRateImageNVViewportCount, which is the one this changes, does run.

[ci-tester-lunarg]

Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build.

[CLAassistant]

All committers have signed the CLA.

[ci-tester-lunarg]

Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build queued with queue ID 71319.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 24074 running.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 24074 passed.

[spencer-lunarg]

@Wint3rNight I was on PTO all of last week and catching up on things, will give this a review by end of the week. It "seems" good, but dynamic state stuff has many sharp edges and I need to read up on these vendor extensions