clamp re-queried extension count in enumeration helpers

[aizu-m]

Tracing the device extension enumeration helpers for the misbehaving-driver case the recent *2KHR clamps covered, the same shape turns up in the plain enumeration paths that fill a loader-internal scratch array.

1. each site queries the ICD for an extension count, sizes a scratch array to it, then calls the Enumerate*ExtensionProperties entrypoint again with that array.
2. the loop over the scratch array is bounded by the count the second call writes back, not by the count the array was sized for.
3. a driver that returns a larger count on the second call walks the loop past the allocation, reading out of bounds of the loader own buffer.

Clamped each loop to the snapshotted allocated count, same idea as the emulation terminators. Six sites: loader_add_instance_extensions, loader_add_device_extensions and check_physical_device_extensions_for_driver_properties_extension in loader.c, terminator_GetPhysicalDeviceToolPropertiesEXT in extension_manual.c, and the two PCI-bus checks in loader_linux.c.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

CI Vulkan-Loader build queued with queue ID 13074.

[charles-lunarg]

All of these two call patterns remind me why I appreciate the helper function I added to vulkaninfo. It takes a function pointer, arguments, and optional default value, then returns (in a std::vector) the contents. Granted its C++ but if the intervening logic wasn't as extensive I'd try to abstract the 2 call pattern here too.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3576 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3576 passed.