loader: apply settings device configurations to device groups

[Wint3rNight]

Fixes #1915.

The settings file's device_configurations list decides which VkPhysicalDevices an app gets to see, but only vkEnumeratePhysicalDevices was honouring it. vkEnumeratePhysicalDeviceGroups didn't look at the settings at all, so an app could still get at a hidden device through a group — which is what makes the validation layer fall over in the issue.

So a group containing an excluded device now gets dropped. It calls loader_apply_settings_device_configurations rather than redoing the deviceUUID/driverUUID/driverVersion matching, so the two paths can't drift apart.

Two calls I made that are worth a second opinion:

I drop the whole group instead of removing the hidden device from it. The devices in a group are physically linked, so a group with a member missing doesn't really describe the hardware anymore. Easy to switch if you'd rather strip.

I also changed phys_dev_group_count_term to count the groups actually written. The copy loop already skips groups with physicalDeviceCount == 0, but the count included them, and new_phys_dev_groups is calloc'd — so a skipped group left a NULL that the memcpy at the end would read. Nothing sets that count to zero today so it was unreachable, but this change makes it reachable.

The count query is still an upper bound, same as the plain path does. Getting it exact would mean fetching every group's contents during a count-only call, which seemed like a bad trade.

One log message got reworded, since it named vkEnumeratePhysicalDevices and the group path calls it now too.

Tests cover a hidden singleton group, a partially hidden group, settings that match nothing, and no settings file at all. Suite's green at 693/693.

[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.