Fortify the clear color iterator

[kvark]

This is another unsound aspect of today's HAL that would be great to fix.

In begin_render_pass we receive an iterator over clear values. It's semantics currently matches Vulkan - a value per attachment, but not necessarily enough for all attachment, and some values are ignored. This is rather sad from the API standpoint, and we should fix it.

Perhaps, we could say that the iterator has to only contain the values for cleared attachments? Given that framebuffer/renderpass creation is rare, we could have the portability layer building a mask of cleared attachments, and then filter the given clear value slice based on that. Shouldn't introduce any visible overhead.

[kocsis1david]

My idea would be to have a key-value pair list, something like a Vec<(u32, ClearValueRaw)>, but it can be also a struct. The key would be the index of the attachment. This way you could build the VkRenderPassBeginInfo.pClearValues array without knowing the render pass. In my opinion it would be more explicit.

[kvark]

@kocsis1david that would certainly ease the life of gfx-portability a bit, at the cost of making the API a bit more verbose, but the user should already know these attachment indices, so it sounds like a good compromise.