Add extension wrapper for VK_KHR_synchronization2

[lothran]

I tried my best to implement Flag64 but i am not a rust god.

[MarijnS95]

We'll have to see where to leave vkCmdWriteBufferMarker2AMD and vkGetQueueCheckpointData2NV.

Don't forget to add empty lines between the functions in synchronization2.rs.

By the way, for all the functions returning void (()) you might as well remove the trailing semicolon ;. That way, if a return type is ever added to a function (or a function is copypasted to implement a new function) a missed return type is immediately a compiler error instead of just a #[must_use]-not-used warning on the vk::Result.
Unfortunately I myself have not been very consistent in doing so with previous submissions either.

Thanks!

[lothran]

Thanks for taking the time really helpful.
I cant think of an easy way to get the correct flag type for formatting in the const KNOWN[(Flag,&str)] array.

For the present the flag>u32::max check seems save there are only the two flag64 types from synchronization2.

[MarijnS95]

@Caradhrass Thanks for your patience, as mentioned in #403 (comment) / #402 (comment) I have already been working on extending vk-parse with the appropriate field to distinguish the 32- and 64-bit variant, even though the all_bits > u32::MAX hack works for now; see #410 / #411 (look at the individual relevant commits, not the total PR diff, that's humongous).

As non-collaborator I am not allowed to mark my own review comments as resolved; feel free to close everything that has to be fixed so that we have a clear overview of what is done.

It remains to be seen what the best order is to merge all these PRs in; we can possibly get your solution in first including the wrapper for Synchronization2, then I'll have to do some conflict resolution to get the proper bitwidth variant on top.
However, I personally prefer to have everything in separate commits in the history: generator changes, n+1 bumps (separate commit for .169, .170, .171), etc. Though that is not up to me to decide, and the intentionally-clean history created in my PRs is anyway lost due to squash merges - unless I make a separate PR per commit 😑

[MarijnS95]

@Caradhrass are you available to discuss how to proceed? My plan is to take in #410 / #411 first to use updated vk-parse for accurately distinguishing 32- and 64-bit fields now and in the future. Feel free to update this PR afterwards to resolve conflicts, but I can do that for you while maintaining authorship.

Sounds good?

[lothran]

Sure, just keep the synchronization2 part of this and I am happy.
That should stay the same regardless of the Flag64 generator used.

[MarijnS95]

You've done an excellent job on the non-raw bindings so there's no reason to drop them nor change authorship 😀

I'll take care of rebasing this when the generator and flags are in, thanks!