fix leaked loader_lock in terminator_CreateHeadlessSurfaceEXT

[aizu-m]

terminator_CreateHeadlessSurfaceEXT, the disabled-extension branch:

loader_platform_thread_lock_mutex(&loader_lock);
...
if (!loader_inst->enabled_extensions.ext_headless_surface) {
    loader_log(...);
    return VK_SUCCESS;   // loader_lock still held here
}

Spotted while reading through the surface terminators after the recent DestroySurfaceKHR change. Every other terminator_Create*Surface* (win32, wayland, xcb, xlib, directfb, macos) reaches its exit through goto out, and out: unlocks loader_lock. This one returns straight out with the mutex still held.

loader_lock is the loader's global lock. Once it leaks the next entry point that tries to take it blocks forever, so a single vkCreateHeadlessSurfaceEXT call made without VK_EXT_headless_surface enabled wedges the whole instance.

Swapped the early return for goto out. result is already VK_SUCCESS at that point and icd_surface is still NULL, so cleanup_surface_creation is a no-op and the function returns the same value as before, only now the lock is released. Brings this branch in line with the other create-surface terminators.

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

[charles-lunarg]

Yet again, good eye!

[ci-tester-lunarg]

CI Vulkan-Loader build # 3604 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3604 passed.