Allow waiting on SwapchainAcquireFuture

[phire]

Changelog:

### Additions
- Allow waiting on `SwapchainAcquireFuture`

Fixes: #1218

It was previously theoretically possible to wait on SwapchainAcquireFuture by dropping it.

But if you dropped it, it became impossible to actually present the image, as then_swapchain_present requires acquire_future to have been joined.

Why might you want to wait for the swapchain acquire?

• Because my machine (Nvidia on Linux) pegs the cpu at 100% if you don't (like, wtf???)
• Because that's what Sascha Willems' samples do
• Because it allows you to lower input latency when running vsynced.

Is this the best design?

There was some discussion on discord about making acquire_next_image return some opaque object that did more things automatically. Or perhaps tracking the acquire state on the image instead of with this future.

But this approach achieve much the same result, and doesn't require invasive refactoring.

[Rua]

It looks good, thanks! Would any of the examples in Vulkano benefit from using this function?

[phire]

Not an easy question to answer.

You could just add it to all of them: They all seem to use PresentMode::FIFO, and you could argue it's a good idea to always wait after acquire when using PresentMode::FIFO, especially if there are driver implementations out there (like mine) that appear to freak out when you don't.

Or you could argue that unless you are actually accepting input, there is no difference between waiting before building the command buffer, or after command buffer submission.

And with a quick skim though the examples, only one (interactive fractal) that actually accepts input.

[Rua]

Shall I merge this as it is then?

[phire]

Yeah probably.

It's not really in-scope of the examples to start worrying about input latency.