release VK_INSTANCE_LAYERS in enable_correct_layers_from_settings

[aizu-m]

Was tracing loader_getenv/loader_free_getenv pairing through the settings-file layer path. One vkCreateInstance with VK_INSTANCE_LAYERS set:

acquire enable_correct_layers_from_settings ENABLED_LAYERS_ENV=0x604000014023 (VK_LAYER_TestLayer)
acquire enable_correct_layers_from_settings ENABLED_LAYERS_ENV=0x604000014023 (VK_LAYER_TestLayer)

Two acquires, no release. settings.c:1163 reads the env var and the out: label just returns res. On Windows loader_getenv hands back a loader_instance_heap_alloc buffer, so that read is owned by the caller. On unix it is plain getenv and nothing is leaked, which is why this stayed quiet.

Two calls because this is the settings-file branch of layer selection, reached from both loader_enable_instance_layers and loader_validate_instance_extensions. Both of those already release their own ENABLED_LAYERS_ENV read at loader.c:4758 and loader.c:5732. The callee was missed, so the string leaks once per call for as long as the process keeps creating instances.

Swept every loader_getenv/loader_secure_getenv site in the loader. This is the only unpaired one. get_unix_settings_path reads four XDG vars without releasing them but is unix-only, where the free is a no-op, so I left it alone.

The test asserts allocator balance for a settings file with an active layer configuration plus VK_INSTANCE_LAYERS. It only detects the leak on Windows, since that is the only platform where the read allocates.

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

[ci-tester-lunarg]

CI Vulkan-Loader build # 3658 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3658 passed.