I feel like people keep mistaking how x264 preset functions.  They often
associate it with their own CPU speed, and I feel the name does not help
with that issue.  I think it may be for the best to just take it out.
At best, it will keep people away from using it unless they know what
they're doing, and at worst, people at least won't be able to associate
it with their CPU as easily anymore.

Change checkbox with text "Advanced Encoder Settings" to "Use Advanced
Encoder Settings".  This way it will hint that the settings will be
disabled when unchecked.

Adds full support for the HD-PVR Rocket

Apparently MPGA is equivalent to MP2, not MP1.

I actually did this because it makes it a bit easier to use with a
build from cross-compiled windows FFMpeg/x264 DLLs.  When compiling on
linux I just have it compile to a custom prefix directory for the
specific windows arch, then I just copy the arch dir back to my windows
HD when complete.  Adding this to the cmake allows me to use the compile
arch directories directly without modification.

Fix device capabilities checking and add "Leave unchanged" option for all settings.

This replaces the ARB_separate_shader_objects extension with traditional
linked shaders.  I was able to get the existing system to use linked
shaders without having to change any libobs graphics API.

This essentially creates a linked list of shader programs with
references to the shaders they link.  Before draw, it searches that
linked list for a particular pixel/vertex shader pair, and the linked
program associated with it.  If no matching program exists, it creates
the program.

QT fakes a mouse move when destructing which is
caught by our filter

This adds a check whether the video format from the device is compatible
with obs. This could either happen if the "Leave unchanged" option is
selected for the video format, or if the driver simply overwrites the
requested video format.

Due to the refactoring of the update function the separation of data
members only to be accessed from inside/outside the capture thread is
no longer needed.

The old implementation of this function assumed that there would be some
settings that could be changed on the fly without restarting the
capture. That was actually never used for any setting.

We don't really need to use a dstr here, simply using the
right format specifier for blog will suffice.

Disable safeseh on 32bit builds

Add interaction support to libobs and support for pumping the events/interaction in gui

This adds an additional option for all settings to leave the current
configuration of the device unchanged.

Since the helper function also needs to pack/unpack the resolution, the
pack/unpack functions were moved to the helper library and prefixed with
v4l2_ in order to avoid possible collisions.

Add disable options for optional plugins, various cmake fixes

Adds:
ENABLE_UI (on by default) which makes it so that the UI is required, and
will fail if a dependency is not found.  This is on by default because
most people are building it with the user interface, and we'll probably
get a lot of issue reports stating "why is there no executable?" if we
don't have this on by default.

DISABLE_UI which forces the UI off.

If neither are set, then the UI will only be built if the dependencies
for it are found, otherwise the UI will be be ignored.

This was added at a time where the source properties dialog did not
pop up automatically on source creation. Now when the properties are
displayed the first device in the select input will be selected by
default if there was none already specified by the source settings.

This will make the code cleaner and also save one redundant round of
device enumeration.

The capabilities flags that were used previously describe all
capabilities the physical device offers. This would cause devices
that are accessible through multiple device nodes to show up with
all device nodes while only one of the nodes might actually offer
the needed video capture capability.

If the device has more nodes the CAP_DEVICES_CAP flag might be set
in which case the device_caps field is filled with the capabilities
that only apply to that specific node that is opened.

This apparently can cause issues with certain modules (as noted by
faruton with his browser plugin)

This prevents certain issues I've encountered with devices where they
expect to shut down in a specific thread they started up in, as well as
a number of other issues, such as the configuration dialogs.

The configuration dialogs require that a message loop be present, and
this was not the case previously because everything was in the video
thread, which has no windows-specific code.

Configuration/crossbar/etc dialogs will now execute correctly.