[ll] First batch of device integration changes [36/..]

[msiglreith]

Merge the first batch of changes from ll into master. Not everything from #1321 is done atm but to avoid that the branch diverges even more from the current master.

This PR contains the most parts of the device integration. We follow the concepts introduced by the next-gen APIs (Vulkan/D3D12/Metal):

• Unified window entry point: Obtain a Surface object from a window, which is a logic representation of a native window/display, and build a SwapChain to the associated Surface. Swapchains are the window interface for the GPU. Every swapchain has an internal backbuffer (list of images) which we can render to and present.

• CommandQueue: Gpu devices offer multiple execution pipelines for graphics, compute and DMA transfer operations. Introducing General/Graphics/Compute/TransferQueues where we can submit now command buffers for execution.

• Synchronization: Offering two synchronization primitives: Semaphore and Fence.
  Semaphore are suited for GPU-GPU synchronization, usually used for synchronizing with the presentation engine by waiting til a backbuffer image has been acquired and present it once the rendering has finished.
  Fences are for CPU-GPU synchronization and are used to ensure that resources can be safely reseted (e.g reset command pools, overwrite memory, ..)

• CommandPool: Command buffers are now combined into pools which are Send but not Sync! So each thread should have it's designated command pool if we want to record commands on it. Once a command buffer has been recorded, a Submit object will be returned which can be send to the main thread for submission to a queue. Be sure to ensure via synchronization primitives that no command buffer is in use when reseting the pool!

• Adapter: Initialization process gets a bit more explicit, similar to the swapchain creation. Adapters are logical representation of the available GPUs of the system. Users can decide which Adapter to open (= device creation) with a desired number of queues.

• Backend: Combining the different new trait implementations into a backend trait (similar to the Resource trait). This should help users to write backend acgnostic code (Surface and SwapChain are window specific!)

[kvark]

OMG IT'S HAPPENING

[kvark]

Thank you for the detailed overview!
I don't think it makes any sense to pick on the details here, given the scale of the PR. We agree on the general direction, so I'm going to merge this and then deal with fallout :)