Closes jp9000/obs-studio#721

This commit adds the ability to copy a scene item's transform and crop
settings and paste those settings onto another scene item in any scene
or scene collection. It also changes the menu shortcut key for the
Transform action "Center to screen" from "C" to "n" because "C" is the
standard shortcut key for "Copy" in most other applications.

Closes jp9000/obs-studio#719

Improves ease of use.

Closes jp9000/obs-studio#731

The operators were unintentionally reversed.

Closes jp9000/obs-studio#724

FFmpeg's AAC encoder is unideal at very low bitrates.

Closes jp9000/obs-studio#722

With the previous Y800 fix a bug was introduced where the format for the
destination frame wouldn't be set if it wasn't Y800, causing a crash.

This enables use of the dedicated GPUs for AMD PowerXpress systems.
Especially important for Adapter selection, as usually the dedicated GPU
is hidden/inactive until needed.

Closes jp9000/obs-studio#706

Because D3D11 specifically does not support an L8 texture format (you
have to use a shader swizzle), manually convert Y800 signals to RGBX
instead.  This also fixes a bug where Y800 signals will render red.

Closes jp9000/obs-studio#718

UI: Fix frontend-api event call for adding scenes

In the filters dialog, when the properties are being updated due to
filters being added/removed/switched, using deleteLater on the previous
view would cause it to linger in the view until the deleteLater is
processed by the Qt queue, displaying two views instead of one.
Additionally because of that, this would also cause the display in the
filters dialog to resize as well, causing the reorder mutex hard lock
which was fixed by the parent commit.

Closes jp9000/obs-studio#714

For displays, instead of using the draw_callbacks_mutex and risk a
reverse mutual lock scenario, use a separate mutex to lock display size
data.

This bug was exposed when trying to reorder filters in the UI module.
The UI thread would try to reorder the filters, locking the filter mutex
of the source, and then the reorder would signal the UI to resize the
display, so the display would lock its draw_callbacks_mutex.  Then, in
the graphics thread, it would lock the display's draw_callbacks_mutex,
try to draw the source, and then the source would try to lock that same
filter mutex.

A mutex trace:
UI thread -> lock source filter mutex -> waiting on display mutex
graphics thread -> lock display mutex -> waiting on source filter mutex

Closes jp9000/obs-studio#714

This commit fixes a bug that would cause the frontend API function
obs_frontend_set_current_scene_collection to never be successful.  Due
to the bug, the following null pointer check would always fail, so the
action would never be triggered.

Modification by Jim: Instead of fixing the typo that caused this to
occur, make it so both scene collection menus and profile menus both use
"file_name" consistently.

Closes jp9000/obs-studio#712

libff: Allow custom demuxer options

If capturing a UWP window, do not fall back to matching windows with the
same window class if the exact window is not found, as this will get any
other UWP window on the system (due to the fact that they all have the
same window class name).

These are helpful for debugging UWP capture issues.

Because the hook cannot get the window handle of UWP windows, fall back
to using the window handle stored in the game capture source itself if
it's unavailable from the hook.

Under certain circumstances, the program may not be able to acquire the
window thread ID for a UWP process, but will be able to acquire the
process ID.  In this case, it should soft fail and retry, rather than
assume it's unacquirable and stop trying to reacquire.

The ApplicationFrameHost process is a sandbox process, and should not be
hooked.

The "attempting to hook [executable]" message would not display the
correct executable if it's fallen back to a different window with the
same window class.

Now that the game capture hook creates and controls all the
synchronization objects, it's no longer possible to expect that the hook
is fully loaded by the time game capture tries to initialize it.  In
that case, allow game capture to retry the hook for a few frames before
assuming something failed.

Remote threads in suspended processes will also start up suspended, so
do not attempt to hook suspended processes.

This detects whether the target process is a UWP process, and then uses
the open_app_* functions for mutexes/events/mapping.  Also slightly
refactors named object open functions.

The only way to open named kernel objects within a UWP "app" is to get
the AppContainer SID, and then open the objects with their full
system namespace names via undocumented NT functions.

Prevents from having to mix ansi/wide string usage for opening UWP
programs.

This function now already exists elsewhere -- open_event_plus_id.

The "Local\" prefix effectively does nothing.

All named objects (including file mapped shared memory) need to be
created within the hook itself due to the fact that UWP programs cannot
access named objects outside of the UWP process.

Because shared memory needs to be created within the hook, the capture
loop cannot start until the shared memory has been filled with valid
data.  Creating an additional "initialize" event fixes this issue.

Additionally, changed the way that named kernel objects are
opened/created.  Before, there were functions that would first try to
open named objects and then implicitly create them if opening failed
(assuming that if the hook didn't create it first, game capture would),
now it's been changed so that you can only either explicitly open or
create.

To check to make sure game capture is still active in the capture
program, it currently uses a named event, and then it checks to see if
that named event exists.  However with UWP programs, you can't open a
named event outside of the UWP process.  FindWindow on the other hand
does work, so instead of checking to see if a named kernel object
exists, create a window and check to see if that window exists.

The "main" windows detected for UWP programs are basically to help
sandbox the programs -- they run in the ApplicationFrameHost process and
help reduce the possibility of other programs trying to access the
actual process window, which is a child window.

To bypass this, go through the list of child windows for the
ApplicationFrameHost window, and then find the one that's attached to
a different process; that different process will always be the target,
and will allows us to open the actual process of the UWP program.

Named pipes cannot be used within UWP programs, so make them optional.

This prevents issues with opening handles to objects within UWP
programs, which have increased security limitations.

Instead of calling OpenThread, use DuplicateHandle with the minimal
access rights (SYNCHRONIZE) to be able to get the current thread handle
within a UWP program.

Adds the ability to use a specific prefix and/or suffix on replay buffer
filenames to distinguish them from normal recordings.  Defaults to
having the prefix "Replay".

Replay buffer and recording should be separate in case the user wants to
start recording from a specific point rather being forced to reconfigure
for regular recording.

Creates a new button on the main window below the recording button for
turning on/off the replay buffer.

It should specify that the user specifically needs to set the "save"
hotkey, not just "the replay buffer hotkey".