(This modifies UI, libobs, deps/obs-scripting, various cmake files)

Found using:
`codespell -q 3 -S *.ini,./UI/data/locale,./deps/w32-pthreads -L aci,dur,iff,mut,numer,uint`

Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed.  Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.

Allows the ability to change the output type in case one service
requires a different output type.

NOTE: This should be considered a temporarily yet simple solution to a
specific problem: support for RTMP-like outputs.  This will allows
seamless integration of supporting different RTMP-like output types
within the same service.  This should probably be replaced with a more
ideal solution later, such as implementing a completely different
service type instead, when time permits.

API changed from:
obs_source_info::get_name(void)
obs_output_info::get_name(void)
obs_encoder_info::get_name(void)
obs_service_info::get_name(void)

API changed to:
obs_source_info::get_name(void *type_data)
obs_output_info::get_name(void *type_data)
obs_encoder_info::get_name(void *type_data)
obs_service_info::get_name(void *type_data)

This allows the type data to be used when getting the name of the
object (useful for plugin wrappers primarily).

NOTE: Though a parameter was added, this is backward-compatible with
older plugins due to calling convention.  The new parameter will simply
be ignored by older plugins, and the stack (if used) will be cleaned up
by the caller.

This is useful for allowing the ability to have private data associated
with the object type definition structures.  This private data can be
useful for things like plugin wrappers for other languages, or providing
dynamically generated object types.

API changed from:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
		obs_encoder_t *video_encoder,
		obs_encoder_t *audio_encoder);

void obs_service_info::apply_encoder_settings(void *data
			obs_encoder_t *video_encoder,
			obs_encoder_t *audio_encoder);

To:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
		obs_data_t *video_encoder_settings,
		obs_data_t *audio_encoder_settings);

void obs_service_info::apply_encoder_settings(void *data
			obs_data_t *video_encoder_settings,
			obs_data_t *audio_encoder_settings);

These changes make it so that instead of an encoder potentially being
updated more than once with different settings, that these functions
will be called for the specific settings being used, and the settings
will be updated according to what's required by the service.

This fixes that design flaw and ensures that there's no case where
obs_encoder_update is called where the settings might not have
service-specific settings applied.

Instead of having services automatically apply encoder settings on
initialization (whether the output wants to or not), instead make it
something that must be explicitly called by the developer.  There are
cases where the developer may not wish to apply the service-specific
settings, or may wish to override them for whatever reason.

API changed:
--------------------------

void obs_output_set_audio_encoder(
		obs_output_t *output,
		obs_encoder_t *encoder);

obs_encoder_t *obs_output_get_audio_encoder(
		const obs_output_t *output);

obs_encoder_t *obs_audio_encoder_create(
		const char *id,
		const char *name,
		obs_data_t *settings);

Changed to:
--------------------------

/* 'idx' specifies the track index of the output */
void obs_output_set_audio_encoder(
		obs_output_t *output,
		obs_encoder_t *encoder,
		size_t idx);

/* 'idx' specifies the track index of the output */
obs_encoder_t *obs_output_get_audio_encoder(
		const obs_output_t *output,
		size_t idx);

/* 'mixer_idx' specifies the mixer index to capture audio from */
obs_encoder_t *obs_audio_encoder_create(
		const char *id,
		const char *name,
		obs_data_t *settings,
		size_t mixer_idx);

Overview
--------------------------
This feature allows multiple audio mixers to be used at a time.  This
capability was able to be added with surprisingly very little extra
overhead.  Audio will not be mixed unless it's assigned to a specific
mixer, and mixers will not mix unless they have an active mix
connection.

Mostly this will be useful for being able to separate out specific audio
for recording versus streaming, but will also be useful for certain
streaming services that support multiple audio streams via RTMP.

I didn't want to use a variable amount of mixers due to the desire to
reduce heap allocations, so currently I set the limit to 4 simultaneous
mixers; this number can be increased later if needed, but honestly I
feel like it's just the right number to use.

Sources:

Sources can now specify which audio mixers their audio is mixed to; this
can be a single mixer or multiple mixers at a time.  The
obs_source_set_audio_mixers function sets the audio mixer which an audio
source applies to.  For example, 0xF would mean that the source applies
to all four mixers.

Audio Encoders:

Audio encoders now must specify which specific audio mixer they use when
they encode audio data.

Outputs:

Outputs that use encoders can now support multiple audio tracks at once
if they have the OBS_OUTPUT_MULTI_TRACK capability flag set.  This is
mostly only useful for certain types of RTMP transmissions, though may
be useful for file formats that support multiple audio tracks as well
later on.

I neglected to surround some files with extern "C", so if something
written with C++ used the files it would cause function exports to not
be mangled by it correctly.

Typedef pointers are unsafe.  If you do:
typedef struct bla *bla_t;
then you cannot use it as a constant, such as: const bla_t, because
that constant will be to the pointer itself rather than to the
underlying data.  I admit this was a fundamental mistake that must
be corrected.

All typedefs that were pointer types will now have their pointers
removed from the type itself, and the pointers will be used when they
are actually used as variables/parameters/returns instead.

This does not break ABI though, which is pretty nice.

Renamed:                       To:
-------------------------------------------------------
obs_source_info::defaults       obs_source_info::get_defaults
obs_source_info::properties     obs_source_info::get_properties
obs_output_info::defaults       obs_output_info::get_defaults
obs_output_info::properties     obs_output_info::get_properties
obs_output_info::total_bytes    obs_output_info::get_total_bytes
obs_output_info::dropped_frames obs_output_info::get_dropped_frames
obs_encoder_info::defaults      obs_encoder_info::get_defaults
obs_encoder_info::properties    obs_encoder_info::get_properties
obs_encoder_info::extra_data    obs_encoder_info::get_extra_data
obs_encoder_info::sei_data      obs_encoder_info::get_sei_data
obs_encoder_info::audio_info    obs_encoder_info::get_audio_info
obs_encoder_info::video_info    obs_encoder_info::get_video_fino
obs_service_info::defaults      obs_service_info::get_defaults
obs_service_info::properties    obs_service_info::get_properties

Renamed:                    To:
-------------------------------------------------------
obs_source_info::getname    obs_source_info::get_name
obs_source_info::getwidth   obs_source_info::get_width
obs_source_info::getheight  obs_source_info::get_height
obs_output_info::getname    obs_output_info::get_name
obs_encoder_info::getname   obs_encoder_info::get_name
obs_service_info::getname   obs_service_info::get_name

The locale parameter was a mistake, because it puts extra needless
burden upon the module developer to have to handle this variable for
each and every single callback function.  The parameter is being removed
in favor of a single centralized module callback function that
specifically updates locale information for a module only when needed.

The 'initialize' callback is used before the encoders/output start up so
it can adjust encoder settings to required values if needed.

Also added the function 'obs_encoder_active' that returns true or false
depending on whether that encoder is active or not.

 - Updated the services API so that it links up with an output and
   the output gets data from that service rather than via settings.
   This allows the service context to have control over how an output is
   used, and makes it so that the URL/key/etc isn't necessarily some
   static setting.

   Also, if the service is attached to an output, it will stick around
   until the output is destroyed.

 - The settings interface has been updated so that it can allow the
   usage of service plugins.  What this means is that now you can create
   a service plugin that can control aspects of the stream, and it
   allows each service to create their own user interface if they create
   a service plugin module.

 - Testing out saving of current service information.  Saves/loads from
   JSON in to obs_data_t, seems to be working quite nicely, and the
   service object information is saved/preserved on exit, and loaded
   again on startup.

 - I agonized over the settings user interface for days, and eventually
   I just decided that the only way that users weren't going to be
   fumbling over options was to split up the settings in to simple/basic
   output, pre-configured, and then advanced for advanced use (such as
   multiple outputs or services, which I'll implement later).

   This was particularly painful to really design right, I wanted more
   features and wanted to include everything in one interface but
   ultimately just realized from experience that users are just not
   technically knowledgable about it and will end up fumbling with the
   settings rather than getting things done.

   Basically, what this means is that casual users only have to enter in
   about 3 things to configure their stream:  Stream key, audio bitrate,
   and video bitrate.  I am really happy with this interface for those
   types of users, but it definitely won't be sufficient for advanced
   usage or for custom outputs, so that stuff will have to be separated.

 - Improved the JSON usage for the 'common streaming services' context,
   I realized that JSON arrays are there to ensure sorting, while
   forgetting that general items are optimized for hashing.  So
   basically I'm just using arrays now to sort items in it.

Add API for streaming services.  The services API simplifies the
creation of custom service features and user interface.

Custom streaming services later on will be able to do things such as:

 - Be able to use service-specific APIs via modules, allowing a more
   direct means of communicating with the service and requesting or
   setting service-specific information

 - Get URL/stream key via other means of authentication such as OAuth,
   or be able to build custom URLs for services that require that sort
   of thing.

 - Query information (such as viewer count, chat, follower
   notifications, and other information)

 - Set channel information (such as current game, current channel title,
   activating commercials)

Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.

I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.)  ..Anyway, the linked list info is also stored in the shared
context data structure.

 - obs-outputs module:  Add preliminary code to send out data, and add
   an FLV muxer.  This time we don't really need to build the packets
   ourselves, we can just use the FLV muxer and send it directly to
   RTMP_Write and it should automatically parse the entire stream for us
   without us having to do much manual code at all.  We'll see how it
   goes.

 - libobs:  Add AVC NAL packet parsing code

 - libobs/media-io:  Add quick helper functions for audio/video to get
   the width/height/fps/samplerate/etc rather than having to query the
   info structures each time.

 - libobs (obs-output.c):  Change 'connect' signal to 'start' and 'stop'
   signals.  'start' now specifies an error code rather than whether it
   simply failed, that way the client can actually know *why* a failure
   occurred.  Added those error codes to obs-defs.h.

 - libobs:  Add a few functions to duplicate/free encoder packets

There were a *lot* of warnings, managed to remove most of them.

Also, put warning flags before C_FLAGS and CXX_FLAGS, rather than after,
as -Wall -Wextra was overwriting flags that came before it.

The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc.  You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.

The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used.  It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:

 1.) Requiring exports to create sources/outputs/encoders/etc meant that
     you could not create them by any other means, which meant that
     things like faruton's .net plugin would become difficult.

 2.) Export function declarations could not be checked, therefore if you
     created a function with the wrong parameters and parameter types,
     the compiler wouldn't know how to check for that.

 3.) Required overly complex load functions in libobs just to handle it.
     It makes much more sense to just have a load function that you call
     manually.  Complexity is the bane of all good programs.

 4.) It required that you have functions of specific names, which looked
     and felt somewhat unsightly.

So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction.  You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.

It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.

The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.

Also, started writing some doxygen documentation in to the main library
headers.  Will add more detailed documentation as I go.

- Add property list callbacks to sources/outputs/encoders so that if
  necessary user interface can be automatically generated or perhaps a
  property list widget can be used for them.

- Change some of the property API names.  obs_property_list_t felt a bit
  awkward when actually using it, so I just renamed it to
  obs_properties_t.

- Removed the getdata/setdata nad getparam/setparam functions from
  sources/services, they will be superseded by the dynamic procedure
  call API.

Add a fairly easy to use settings interface that can be passed to
plugins, and replaced the old character string system that was being
used before.  The new data interface allows for an easier method of
getting/altering settings for plugins, and is built to be serializable
to/from JSON.

Also, removed another wxFormBuilder file that was no longer in use.

With the permission of my fellow contributors, I'm switching obs-studio back to GPL v2+ to prevent issues between this project and the original OBS project, and for personal reasons to avoid legal ambiguity (not political reasons, I admittedly would prefer GPL v3+)

cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing