Convert all code to Rust 2018 edition

[Rua]

• Added an entry to CHANGELOG_VULKANO.md or CHANGELOG_VK_SYS.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes - in this repository
• Updated documentation to reflect any user-facing changes - PR to the guide that fixes existing documentation invalidated by this PR.
• Ran cargo fmt on the changes

This converts the whole codebase to use the 2018 edition of Rust. This mostly involves how use statements work. I've also fixed some of the less pedantic performance and style issues that clippy pointed out. There should be no functional changes, only in the code.

[Eliah-Lakhin]

@Rua Is it a prerequirement for some major work?

[Rua]

No not really. I came across this while experimenting with Ash, and then decided to make a PR for it. I was kinda surprised Vulkano was still running on Rust 2015.

[Eliah-Lakhin]

@Rua Would you mind if we postpone with the major code style change across the codebase? I like most of what clippy is proposing, and I constantly see a lot of the code that needs to be fresh up too, but I just don't think this is a good moment for this update. We are still in the API functional prototyping phase, I think that it would be better to make cleanup right before v1.0. Otherwise we will have to keep making it from time to time and it would mess with other people work in progress etc. Normally, I think that the codestyle should be established through the process of wider community discussion and maybe even enforced by Continuous Integration checks. At this moment we only enforce rust-fmt basic format.

[Rua]

So just the edition change, no clippy? I can do that.

[Eliah-Lakhin]

@Rua Yes, let's make edition change only for now. I hope there are no 3rd party projects relaying on the older edition. Thank you!

[Rua]

Ok, here's a cleaner version that only changes to 2018.

[Eliah-Lakhin]

@Rua Still a lot of changes, though.

How do you think would it be feasible to finish #1430 in upcoming 0.22.0 release(let say within this month)? I would prefer to finish #1430 first because there is a work in progress that was already split between PRs(starting from #1504), and then as a very least change include this PR's migration into release. The problem with managing of the codebase wide PRs such as this one is that it's difficult to manage for me of what and where was changed. I want to keep track at least until we finish the minor release.

[Rua]

I think I can do that, yes.

[Rua]

Now that the execute_commands PR has been merged, what are the plans for this one?

[Eliah-Lakhin]

@Rua Then plan is to merge #1517 then I will ask you to review this PR again and update missing things regarding the recent merges to master, and then I will proceed with release 0.22.0. All other PRs will be held until the next release.

[Eliah-Lakhin]

So many breaking changes in upcoming release... I think I will have to write migration instructions and pin it to Github Issues once we released.

[Eliah-Lakhin]

@Rua Could you please verify this PR again to make sure it is covering the recent changes in master?

[Rua]

It looks good, ready for merging. :)

I would recommend also merging #1523 for the next version, it seems useful and doesn't break anything.

[Eliah-Lakhin]

@Rua Merged 👍

I also merged #1523, but it resolves the issue only partially(see my comments).

[Eliah-Lakhin]

Windows build is failing due to https://status.chocolatey.org/ outage. I think this is temporary.

[Eliah-Lakhin]

@Rua Good catch! Thanks!