Move to manual management of descriptor set and command buffer allocators

[marc0246]

Changelog:

### Breaking changes

Changes to command pools:
- Renamed `CommandPool` to `CommandBufferAllocator`, `StandardCommandPool` to `StandardCommandBufferAllocator`, and `UnsafeCommandPool` to `CommandPool` to better reflect their action.
- Removed `Device::with_standard_command_pool`.
- Command buffer allocators must now be managed manually.
  - `AutoCommandBufferBuilder::{primary, secondary}` now take an implementation of `CommandBufferAllocator` instead of the `Device`.
  - `DeviceLocalBuffer::{from_buffer, from_data, from_iter}` and `ImmutableImage::{from_iter, from_buffer}` now take an implementation of `CommandBufferAllocator`.

Changes to descriptor pools:
- Renamed `DescriptorPool` to `DescriptorSetAllocator`, `StandardDescriptorPool` to `StandardDescriptorSetAllocator`, and `UnsafeDescriptorPool` to `DescriptorPool` to better reflect their action.
- Renamed `SingleLayout[Variable]DescPool` to `SingleLayout[Variable]DescriptorSetPool` for consistency.
- Removed `Device::with_standard_descriptor_pool`.
- Descriptor set allocators must now be managed manually.
  - `PersistentDescriptorSet::{new, new_variable}` now take an implementation of `DescriptorSetAllocator`, `PersistentDescriptorSet::new_with_pool` has been removed.

In two of my previous PRs I addressed some performance concerns around the standard implementations of (then) descriptor and command pools. One of the optimizations involved removing the layer of Mutex that was used to store these pools inside the device. My idea was to use thread-local storage as a solution with almost no overhead that would also work as conveniently as before, but after some discussion on Discord it was pointed out that in certain edge-cases, the TLS might keep Devices alive that have already been dropped by the user. Because of that, putting the burden of managing these (then) pools onto the user seems inevitable, otherwise we would have to sacrifice some of the performance gains for a bit of convenience.

Other than that, the "pool" and co. types have been renamed to hopefully be less confusing to someone coming from Vulkan, as they function quite differently. Also, AutoCommandBufferBuilder can now be constructed using arbitrary implementations of CommandBufferAllocator.

I have tried to do StandardMemoryPool in this PR as well, but quickly realized that CpuBufferPool wasn't made with manually-managed memory allocators in mind, so I decided to do that in an upcoming PR together with my revamp of memory allocation in vulkano.

[Rua]

It all works and looks good. It will be a big change for Vulkano, so hopefully there's no hidden bugs and users won't be too confused by it.

[marc0246]

Agreed. I would have preferred to keep this automatic, but in the end this will be both faster and more flexible for the user, so hopefully people will take kindly to it.