* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* Instead of patching e.g. PRESENT to GENERAL early, we keep the 'real' layout
even if that's UNDEFINED or PRESENT or whatever. We then do a last-second
patchup whenever we're actually transitioning images in vulkan itself, to set
the right layout.
* This requires us to do the patching in a few more places - anywhere like
texture rendering or initial states where we want to go from current state ->
custom state -> back to current state.
* This also allows us to more gracefully handle PREINITIALIZED image layouts. We
internally promote them to GENERAL as soon as possible, but keep them around
as PREINITIALIZED for display.
baldurk