* Both command lists and command queues need to be able to access this
data so we expose it in a common place.
* This gets command stepping partially working.
* In a couple of places I had to resort to if(IsHighContrast) but mostly
this is just using system brushes consistently or not assuming black
text.
* The default DockPanel theme doesn't work well, so make a minimal high-
contrast theme for it and assign it everywhere.
* The pipeline flow was using fixed colours, use system brushes for the
different elements and switch based on high-contrast to ensure active
and inactive stages are visible (using ActiveCaption looks bad on
normal themes because it's a big block of colour).
* For some reason the flat toolstrip renderer doesn't handle white-on-
black themes, but the system one does. It's a little clunkier but it
shows up correctly without writing tons of custom painting code.
* Range histogram uses a properly contrasting colour for the border.
* Treelist views use a better system colour for selected rows when
inactive and hovered rows (when high contrast).
* Mesh view grids have a system background instead of white
* Various things (pipeline state, mesh viewe) set text colour when
colourising backgrounds of things instead of assuming black.
* After clang-format re-arranged headers, the definition of
WrappedID3D11Device was no longer visible from d3d11_context.h, but
instead just the pre-declared "class WrappedID3D11Device;"
* This meant the function didn't correctly upcast to the right parent
type and left the return value with the wrong vtable which would crash
* The remote server is going to start being responsible for more things
soon, and one of those is launching programs to capture. Since this is
remote code execution by design, we want to be able to lock down who
can communicate with the server.
* By default, only private LAN IP ranges are listened to.
* No fixed nvidia driver has been released, and since there is an easy
workaround that doesn't break any other IHV's drivers, temporarily do
that until nvidia's driver is working again.
* We half-expect the first attempt to fail, and we want to ignore any
debug message spew from that failed compilation - if we fail after
patching, we print out the output log then.
baldurk