Implement new locking for UnsafeBuffer and UnsafeImage

[Rua]

Changelog:

- **Breaking** Removed the `try_gpu_lock`, `increase_gpu_lock` and `unlock` methods from the `BufferAccess` and `ImageAccess` traits. Locking is now implemented internally in `UnsafeBuffer` and `UnsafeImage`.

This adds new and better resource locking for buffers and images. Locking is performed in UnsafeBuffer and UnsafeImage instead of in the individual "safe" types, so if multiple safe types share a common buffer/image, the locking still works properly. The locks for buffers are now granular at the byte level, so it is possible to lock one range of a buffer while leaving other ranges untouched. For images the same thing applies, but it is granular at the level of aspect/mip level/array layer.

To make this possible, I've had to use an existing crate, rangemap, and make changes to it so that it would fit Vulkano's needs. This PR uses a fork of rangemap on my personal repository, which is probably ok for now but needs a better solution in the long term (before 0.30 is released anyway). It could be merged fully into Vulkano, but then its git history will be lost. @AustinJ235 proposed making it a repository under the Vulkano project, which is also a possibility.

This PR is the first in what will be a series of PRs tackling different parts of Vulkano's synchronization. For that reason, I have not included all changes in the changelog entries: things are not yet in the final state and will probably change again before the next release. It is also quite likely that some things don't work properly at the moment. The texture_array example crashes, but I know what the cause is and it should be fixed in one of the followup PRs.

[Eliah-Lakhin]

@Rua I forked rangemap to our organization, and I'm going to give you write access to the fork, but I can't do it right now because there are issue with GitHub. Once Github fixed it, you can change the route in Cargo.toml.

Overall the PR looks good, I didn't detect any issues, so it is good to go.