Add basic OSX AV capture plugin

Currently only cameras using interleaved 4:2:2 YCbCr are supported, e.g.
recent internal iSight cameras
Merge pull request #72 from fryshorts/pulse-input

Several Improvements to the pulseaudio capture
async vid.: Fix potential endless buffering issue

If a source with async video wasn't currently active, it would endlessly
buffer the video data, which would cause memory to grow endlessly until
available memory was extinguished.

This really needs to be replaced with a proper caching mechanism at some
point.
Hide audio captures as sources in basic mode

Still not 100% decided on this, but I already see people getting
confused over this, so I'm just going to hide them for the time being.
Mac A/V capture:  Fix minor issue

Use the port clock instead of the master clock
Fix Obj-C property usage

...I really need to go through my Objective-C reading material
Fix jannson_config.h for vs proj files
Revert hiding of audio sources tyeps
GL/D3D11:  Add scissor support
Enable GL vertex attribute normalization

Fixes GL vertex color attributes
d3d11:  Fix float3 constant alignment (128bit)
Make workaround for VS2012/2013 debugging issue

Starting with VS2012, microsoft made a terribly stupid change to the way
working directory is handled.  It basically will not work properly if
you need to run your executable from a specific location, it would only
run properly from debug if you also had your target directory set to an
environment variable, which was incredibly stupid.  The visual studio
development team is run by chimpanzees with tiny brains, headed by
a broken AI core designed by gilbert gottfried.

I made a workaround for it so that it's much easier to set up debugging
in VS2013, so that all you need to do is enter in the the working
directory for it to work properly.  Still somewhat of a pain but the Qt
addin kept overwriting the god forsaken environment path, and made
setting it up much more difficult than it was supposed to be.
Also fix project files for 64bit
D3D11:  Fix constant position code for good

I had forgotten how constants worked when compiled; constants are
uploaded as constant registers.  When constants are used with shaders,
multiple constants are often packed in to a single register when
possible to reduce constant register count.

For example, one 'float' constant and one 'float3' constant will be
packed in to a single register (c0.x for constant 1, c0.yzw for constant
2), but two 'float' constants and one 'float3' constant must inhabit two
registers (c0.xy for constant 1, c1.xyz for constant 2), so it must
start on a new register boundry (every 16 bytes).

I had first instinctively thought it was just a simple case of
alignment like it is on the CPU, but then I realized that it didn't
sound right, so I went back and did some more tests and then ultimately
remembered how constants actually are uploaded.
D3D11 scissorrect fix

Make sure the D3D11 scissorrect settings actually get applied.
Add contribution guidlines

These are guidelines, not necessarily a rulebook.
Add (temporary terrible) volume controls

 - Add volume control

   These volume controls are basically nothing more than sliders.  They
   look terrible and hopefully will be as temporary as they are
   terrible.

 - Allow saving of specific non-user sources via obs_load_source and
   obs_save_source functions.

 - Save data of desktop/mic audio sources (sync data, volume data, etc),
   and load the data on startup.

 - Make it so that a scene is created by default if first time using the
   application.  On certain operating systems where supported, a default
   capture will be created.  Desktop capture on mac, particularly.  Not
   sure what to do about windows because monitor capture on windows 7 is
   completely terrible and is bad to start users off with.
Fix a few typos
Fix an issue with async (video) source destruction

obs_source_output_video can cause cached frames to be freed twice if
called with a partially destroyed source, among other undesirable
effects; freeing the source private data right after the destroy signal
has been processed ensures proper behavior
obs-source.c:  Fix a few potential concerns

First, if the private data of the source fails to be created, then do
not destroy the source.  If the source is destroyed, all the user's data
associated with that source is lost, which could end up being a
potential problem.  Instead, let it linger as a 'dead' source until the
user chooses to fix the problem (though this should never really happen,
the source module functions should be programmed to handle this
scenario)

Secondly, rename new_frame_ready to ready_async_frame, and fix a
potential memory leak with it.