Merge MappedDeviceMemory into DeviceMemory, make MemoryAlloc reuse the logic

[marc0246]

Changelog:

### Breaking changes
- `Subbuffer::mapped_ptr` was replaced by `Subbuffer::mapped_slice`.
- `MemoryAlloc::new` no longer returns a `Result`, and doesn't map the `DeviceMemory` automatically anymore.
- `MemoryAlloc::mapped_ptr` and `MemoryAlloc::mapped_slice[_mut]` were replaced by `MemoryAlloc::mapped_slice`, which returns a pointer.
- `MemoryAlloc::{invalidate, flush}_range` now take a `MappedMemoryRange` as argument.

### Additions
- Added `DeviceMemory::{map, unmap, mapping_state, invalidate_range, flush_range}`, `MappedDeviceMemory` has been deprecated.
- Added `MemoryMapInfo`, `MemoryUnmapInfo`, `MappingState` and `MappedMemoryRange`.

### Bugs fixed
- Fixed potential UB when using `MemoryAlloc::try_unwrap`, where the allocation was mapped on contruction of the `MemoryAlloc` but not unmapped on unwrapping, allowing double-mapping.
- Fixed a bug in `GenericMemoryAllocator::allocate`, where the root allocations weren't created with the configured `AllocationType`.

[Rua]

The VK_KHR_map_memory2 extension provides updated versions of some of these functions. It's not used by anything in Vulkan yet, but at least Vulkano would be ready for anything that does in the future.

[marc0246]

The VK_KHR_map_memory2 extension provides updated versions of some of these functions. It's not used by anything in Vulkan yet, but at least Vulkano would be ready for anything that does in the future.

Yes, that's why I added a MemoryMapInfo struct.

[marc0246]

I missed, however, that VkMemoryUnmapInfoKHR and VkMemoryUnmapFlagsKHR existed as well. And I messed up the naming of the ones for mapping. Oops.

[Rua]

Everything is good now, thanks!