This is a band-aid solution to be able to create temporary services
without logging them and keep them out of enumeration functions.

This is a band-aid solution -- 'master obs context lists' should not be
kept by the core.  Logging of object creation/destruction should also be
controlled by the front-end instead of the core.

The intention of this is to allow sources/outputs/etc to be created
without being visible to the UI or save/load functions.

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.

The private type data is the type_data variable that's provided when
object types are registered by plugins.

Allows objects to be created regardless of whether the actual id exists
or not.  This is a precaution that preserves objects/settings if for
some reason the id was removed for whatever reason (plugin removed, or
hardware encoder that disappeared).  This was already added for sources,
but really needs to be added for other libobs objects as well: outputs,
encoders, services.

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.

Before:                After:
obs_service_gettype    obs_service_get_type

It seems there was an API function that was missed when we were doing
our big API consistency update.  Unsquishes obs_service_gettype to
obs_service_get_type.

This Fixes a minor flaw with the API where data had to always be mutable
to be usable by the API.

Functions that do not modify the fundamental underlying data of a
structure should be marked as constant, both for safety and to signify
that the parameter is input only and will not be modified by the
function using it.

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

Instead of having functions like obs_signal_handler() that can fail to
properly specify their actual intent in the name (does it signal a
handler, or does it return a signal handler?), always prefix functions
that are meant to get information with 'get' to make its functionality
more explicit.

Previous names:             New names:
-----------------------------------------------------------
obs_audio                   obs_get_audio
obs_video                   obs_get_video
obs_signalhandler           obs_get_signal_handler
obs_prochandler             obs_get_proc_handler
obs_source_signalhandler    obs_source_get_signal_handler
obs_source_prochandler      obs_source_get_proc_handler
obs_output_signalhandler    obs_output_get_signal_handler
obs_output_prochandler      obs_output_get_proc_handler
obs_service_signalhandler   obs_service_get_signal_handler
obs_service_prochandler     obs_service_get_proc_handler

Previous names:             New names:
-----------------------------------------------------------
obs_view_setsource          obs_view_set_source
obs_view_getsource          obs_view_get_source
obs_source_getdisplayname   obs_source_get_display_name
obs_source_getwidth         obs_source_get_width
obs_source_getheight        obs_source_get_height
obs_filter_getparent        obs_filter_get_parent
obs_filter_gettarget        obs_filter_get_target
obs_source_filter_setorder  obs_source_filter_set_order
obs_source_getsettings      obs_source_get_settings
obs_source_getname          obs_source_get_name
obs_source_setname          obs_source_set_name
obs_source_setvolume        obs_source_set_volume
obs_source_getvolume        obs_source_get_volume
obs_scene_getsource         obs_scene_get_source
obs_scene_fromsource        obs_scene_from_source
obs_scene_findsource        obs_scene_find_source
obs_output_getdisplayname   obs_output_get_display_name
obs_output_getname          obs_output_get_name
obs_encoder_getname         obs_encoder_get_name
obs_service_getdisplayname  obs_service_get_display_name
obs_service_getname         obs_service_get_name

With the recent change to module handling by BtbN, I felt that having
this information might be useful in case someone is actually using make
install to set up their libraries.

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.