Support VK_EXT_frame_boundary in addition to vkQueuePresent

[solidpixel]

We currently only detect frames when the application submits to a present queue. For some use cases, including headless test builds on llvmpipe, this never happens. To support these use cases we should expose the VK_EXT_frame_boundary extension to allow applications to manually indicate frame boundaries.

[solidpixel]

Summary of required changes.

The layer needs to expose the extension availability via vkGetPhysicalDeviceFeatures2(), storing whether the driver supported it in the layer per-instance config, and overriding the value return to the driver to indicate that it's enabled even if the driver doesn't support it.

On calls to vkCreateDevice(), if the underlying driver did not support the extension, we must remove the extension enable structure from the list passed to the driver by editing safe-struct copy of the create info that we then pass to the driver.

On calls to vkCreateDevice(), if the underlying driver did not support the extension, we must remove the extension enable structure from the list passed to the driver by editing safe-struct copy of the create info that we then pass to the driver.

On calls to vkQueueSubmit(), vkQueueSubmit2() (and KHR version), vkQueuePresentKHR(), and vkQueueBindSparse(), we need to monitor the frame ID and use that to trigger frame boundaries in the layer. If the driver did not expose support for the frame boundary extension, we must remove the extension structure from the parameter structure passed down to the driver.

Note, the current protocol for Mali Timeline assumes that frames are monotonically increasing, and cannot handle multiple in-flight frames that are concurrently using Vulkan from different threads.