Currently, no backend sets this, and it is not displayed.

Currently, no backend sets them, and they are not displayed.

Before, if a row was selected, the color was completely replaced, which
makes the color preview column completely useless for that row.

This change also fixes some inconsistencies with how the selection hover
works on tree widgets; previously part of the row was not highlighted.

This is already implemented by all backends, but did not get displayed
beforehand. This column is not visible by default.

This has not yet been implemented by any backends, not is the column
visible by default.

They have not yet been implemented by any backends, not are the columns
visible by default.

The first one is a simply a typo.

The second one seems to be an unnecessary value that doesn't make sense
(as blend factors are ignored when blendEnable is false, and setting the
source color blend factor to the destination color seems like an
uncommon situation (the equivalent to blendEnable being false is
source = 1, dest = 0). This does not seem to be a driver bug, as
the commit that added it (5043898) does
not mention that nor does it seem to work around other driver bugs.

The third one is that VulkanDebugManager::PixelHistoryCopyPixel was
declared but never defined. VulkanPixelHistoryCallback::CopyImagePixel
serves the same purpose.

Before, the buffer could be overrun, which could result in anything from
garbage data to the GPU device being lost to segfaults. Now, correct
data is gathered.

We can't know in advance how many primitives will hit the targetted
pixel, so it's not possible to create the buffer until after our first
pass for each events (fortunately we do know the number of events in
advance). It is possible that we don't need a larger buffer, though,
in which case the original one can be re-used.