* cbuffer and input registers no longer have any names elided into them, they
are 'raw' registers. The source mapping provides the information of where they
come from as best as possible.
* Since we're now using source-mapping for constants, fix some source mapping
issues with arrays, nested structs/arrays, and matrix major-ness.
* Moving away from 'registers' explicitly being stored, we now have a single
variable array where the shader representation is responsible for allocating
it.
* In DXBC we calculate the number of each type of mutable variable (temps,
indexable temps, and outputs) and assign slots linearly.
* We also update some naming - high-level variables aren't "locals" since they
could be globals too, and debugging variables aren't "registers" but simply
the variables we use for debugging which may be more complex than float4 for
other APIs.
* The local variable matching by string name is unnecessary for this change
but will be more useful in future after further refactors where there isn't
a single list of variables to index into at the upper level.
* This avoids having the UI need to do a scan and expecting to find
"instruction:" on the start of a line.
* We also move the callstack to be stored per-step, and not in the line info
mapping.
* It identifies some potential overflows which we know likely won't happen, but
the fixes are harmless.
* Some issues are definitely bad, though not actual bugs.
* This is needed so that the functional tests can elevate and run renderdoccmd
to register the vulkan layer, if needed.
* At the same time remove the old spammy message and ignore flag - this dates
back to before the UI existed, and that should be the way users run RenderDoc
generally and it has a good UI for walking through layer registration if
needed.
* The command is always available, but will only show up in help if attention is
needed.
* Also fix registering installs on shared drives.
* Mostly moving includes from common headers to cpp where possible, and removing
includes of the whole thing where only enums or rdcstr etc are needed.
* On APIs like vulkan the view casting happens from an already typed format, so
don't assume that casts are only applied when the underlying format is
typeless. When a cast is not valid the view format should never be different
from the underlying image format as the API should never make it possible to
validly create or bind a view with a different format.
baldurk