This is just for accessing a json object.  I should be using obs_data_t
for this instead of json directly, but it doesn't really matter.

Allows the ability to get a module-specific configuration file/path

API Changed:
---------------------------
From:
- bool obs_startup(const char *locale, profiler_name_store_t *store);

To:
- bool obs_startup(const char *locale, const char *module_config_path,
		profiler_name_store_t *store);

Summary:
---------------------------
This allows plugin modules to store plugin-specific configuration data
(rather than only allowing objects to store configuration data).  This
will be useful for things like caching data, for example looking up and
storing ingests from remote (rather than storing locally), or caching
font data (so it doesn't have to build a font cache each time), among
other things.

Also adds a module-specific directory for the UI

If a user was using FFmpeg output before pathc 0.12.0, they had to type
in the full file name to the FFmpeg output URL/Path box, which isn't
exactly compatible with the new settings.

This changes each profile's config file so that the FFmpeg output
detects whether files are used, and then extracts the file's directory
and extension and sets them accordingly to make it compatible with the
new FFmpeg file output handling.

This changes the way the advanced output section's FFmpeg output
settings work by allowing the user to select whether they want to output
to a file or output to a URL, and makes it so file names are
automatically generated like other recording outputs.

If they choose to output to a file, it'll only require an output
directory similarly to how other recording outputs work.  They can
select a directory to output to rather than being required to type in a
full path and filename; the filename is automatically generated.  The
extension is also automatically retrieved from libff depending on the
format selected.

Otherwise if they have Output to URL selected, it'll show a simple edit
box where they can type in the target URL.

Manually specifies the UTF-8 character codes used by the file rather
than relying on the compiler to determine what the codes are manually.
I was getting compile errors due to the fact that my current code page
is not at the default code page; so visual c++ tried to use my current
code page rather than UTF-8 and it would cause an error on the file.

Apparently using QPointer container for the QObject being given to the
connect function makes it so it can't find the actual function to use.
I'm guessing this is incomplete functionality or a bug that existed in
GCC 4.8.  Doesn't happen in 4.9+.

When settings the base resolution, try to find the closest output
resolution to the old output resolution, and use that for its value.  If
the aspect ratio is about the same, then don't modify the value.  If the
aspect ratio is significantly different, then find the closest
approximation while keeping with the new aspect ratio.

This particular issue has been an annoyance for quite some time.

When getting a blank module data file (indicating you want to get the
path to the module data directory itself), on certain operating systems
(windows) it will fail if you end the path with '/' or '\'.  So simply
make sure that if a blank module sub-path is used, don't try to append a
slash.

This reverts commit 74354dc4.  I really
shouldn't have modified this, especially not in this way.  Was the wrong
approach.  The thing I was trying to fix was very rare as well.

The return value is supposed to be a boolean value; not NULL.

When a window being captured is closed, it never tries to reacquire.
This just searches for the window in video_tick and reacquires if the
currently set window is found again.

Closes jp9000/obs-studio#465

It's best to do the global curl initialization separately before any
curl functions are called.  Prevents initialization threading issues.

Apparently the site has been dissolved and/or bought out.  It seems it
will reform as something else later on in the future.

This URL is set via cmake instead of being baked in to the actual source
code.

I made the rather tough call of not showing all services by default; I
didn't want to have to do this, but too many services are asking to be
put in to the program, and any time I add a service in to the list, I
feel uncomfortable because I feel like I'm potentially advertising them,
and/or they're using our program to advertise as well.  Some of these
services are particularly bad at policing illegal/copyrighted content,
host content that I personally find distasteful or incredibly stupid
(what the heck is up with these "vaping" streams?), or are just fairly
terrible websites in general that I just feel uncomfortable with showing
by default.

However, I do not really want to reject anyone either, I want to let
their users be able to use our program with relative ease, but more than
anything I just simple don't want to be seen as "endorsing" some of
these websites (more than others in particular).  I know that a "show
all services" checkbox is probably pretty pointless/superfluous thing to
do, but I feel like it's at the very least a means of saying "hey, I
don't really endorse these guys," or "use at your own risk," or
"warning: this website is incredibly terrible."

Honestly, I couldn't really think of any better solution that would
 a.) still list all services without outright censoring them, and
 b.) prevent us from being seen as "endorsing" all services.

(Although maybe this whole thing feels a bit.. passive aggressive.  I
feel like I'm tipping over someone's garden gnome in the middle of the
night while they're sleeping.  Still, it's something.)

NOTE: This code is backward compatible; i.e., if you previously had a
service selected that's not common but don't have the "show all"
checkbox checked, it'll still show that service for convenience.

Services almost always recommend this be enabled, and I generally want
to make configuration easier for users; with CBR they don't have to set
things like the CRF value.

Just a little helper function that allows you to create an obs_data_t
object from a json file (rather than having to manually open it each
time and then call obs_data_create_from_json on the file data)

My fault; should have realized that this would be better to do.  Uses
"obs-studio" as the name, and includes the version (same format as the
others)

This will help ensure the receiving end knows that OBS is being used.

Closes jp9000/obs-studio#464

Different logging can occur from different contexts.
This adds isolation for each context passed to the
AV log.

Adds a log message whenever the source is created or updated
containing all the properties set to help debugging remote
users' problems.

test: Update Windows test application for windowless contexts

The rationale for rejecting these register calls is that these functions
may be required for the plugin to work properly, which can't be
guaranteed when libobs doesn't know about them.

This behavior may be revisited once the plugin manager is implemented,
to e.g. make it configurable (potentially per plugin) to allow loading
newer plugins in case they are known to work with the older libobs

Previously adding new required functions would cause libobs to read out
of bounds in plugins not built with the new additions

The id and parent_id fields should now allow better recovery of the
actual call trees, though they aren't compatible between different data
dumps in a single profiler session anymore; for that reason the new
fields name_id and parent_name_id are introduced, they hold the old id
and parent_id values respectively

Microsoft's C++ compiler doesn't initialize all members properly without
this

The single darray solution was potentially unsafe since you're not
allowed to modify the (encode) buffer between calls to
complex_input_data_proc which is potentially violated if the darray
had to be resized due to capacity being < 2 * in_bytes_required