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".

This output allows buffering the encoded data, and then muxing the
current buffer to a file on the spot via a hotkey the user sets.

Prevents reallocation of encoded packet data.

Deprecates:
obs_duplicate_encoder_packet
obs_free_encoder_packet

Replaces those functions with:
obs_encoder_packet_ref
obs_encoder_packet_release

On MSVC, deprecated types/functions were being completely ignored by the
compiler due to this pragma.  Any plugins/programs that depended on this
would also have this warning disabled due to it being in this file.
This pragma was most likely originally done due to the MSVC warnings for
C-standard functions, which are now ignored via _CRT_SECURE_NO_WARNINGS
on all projects instead.

There's no need to have two separate macros to declare something as
deprecated.

This prevents issues with using standard C functions, where microsoft
would otherwise spit out pointless warnings to encourage using
microsoft-specific functions instead.

When an output's context data is being created, it cannot register any
hotkeys because the output has not initialized its reference counting
capability.  This is due to the fact that when a hotkey is registered,
it creates a weak reference to the source/output/service/encoder.

The solution to this is to make sure the output's reference counter data
is created before calling the create callback.

(Note: This commit also modifies the UI)

Being able to generate file names based upon a specification is useful
for more than just the UI; it can also be useful for things such as the
replay buffer where file names need to be generated on the fly.

Allows getting pointer to an offset at a specific index within the
circlebuf data.  Useful for iterating through circlebuf data.

Fixes a case where OBS would prefer trying to connect
to an IPv4 address even though you had bound it to an
IPv6 interface for example.

rtmp-services: remove shut down services

rtmp-services: Update ingests list for Restream.io

This reverts commit 0edaebe1.

The commit was actually less optimal than it was before.  Shaders are
always fully unfolded and both sides of a branch are always executed.
Despite that fact, the "avoid branching" commit actually *added* two
extra unnecessary instructions with the same number of actual sample
instructions, making it arguably less optimal than before.

This was tested via the D3DDissamble function.

Adds options to start output timers every time streaming or recording
has started.

Closes jp9000/obs-studio#668

The xcb message queue is not currently emptied.  If errors are generated
by any void requests the message queue will simply fill up and messages
will never be deleted.

Due to a (currently unknown) other problem this happens for me, and
results in OBS using up all memory with a queue that will never be
emptied.

Here we add a poll loop that will empty the xcb message queue and
discard the messages.  While this means that errors are still not
handled, OBS wont end up crashing either.

Closes jp9000/obs-studio#675