win-capture: Separate window finding source code

Because other capture methods may end up needing to share this code,
separate the window finding source code to window-helpers.c and
window-helpers.h.

This include a function to fill out a property list with windows, a
function to find a window based upon priority/title/class/exe, and a
function to decode the window title/class/exe strings from a window
setting string.
Update to version 0.6.2
linux-pulseaudio: Fix the default req. buffer len

This changes the the requested buffer length to 25ms.
linux-pulseaudio: Use defaults for pa_buffer_attr

Although these values aren't used in capture mode, set these to the
default values just to be safe.
linux-pulseaudio: Force stereo if unknown layout

This adds a check to change the capture settings to use 2 channels when
a channel number is encountered that would otherwise be interpreted as
SPEAKERS_UNKNOWN.
Update Ubuntu PPA install instructions
Merge pull request #286 from dodgepong/master

Update Ubuntu PPA install instructions
Fix sources context menu "Remove" shortcut for OSX
Add "Remove" shortcut to scenes context menu
Fix "Remove" shortcut (Del) to work for both scenes and sources
Add "Rename" entry to scenes context menu
Disable double click renaming for both scenes and sources
Open source properties on double click
Sparkle-Updater: Select delta update if available
Change default audio smoothing threshold to 50ms

70 milliseconds is a bit too high for the default audio timestamp
smoothing threshold.  The full range of error thus becomes 140
milliseconds, which is a bit more than necessary to worry about.  For
the time being, I feel it may be worth it to try 50 milliseconds.
Fix a typo ('timetamp')
Add flag to obs_source_frame for unbuffered video

Add 'flags' member variable to obs_source_frame structure.

The OBS_VIDEO_UNBUFFERED flags causes the video to play back as soon as
it's received (in the next frame playback), causing it to disregard the
timestamp value for the sake of video playback (however, note that the
video timestamp is still used for audio synchronization if audio is
present on the source as well).

This is partly a convenience feature, and partly a necessity for certain
plugins (such as the linux v4l plugin) where timestamp information for
the video frames can sometimes be unreliable.
linux-v4l2: Add 'unbuffered' property

This allows the user to select whether to use unbuffered video or not.
Unbuffered video cause the video frames to play back as soon as they're
received, rather than be buffered and attempt to play them back
according to the timestamp value of each frame.
Use MAX_TS_VAR for timestamp jump detection

This combines the 'direct' timestamp variance threshold with the maximum
timestamp jump threshold (or rather just removes the max timestamp jump
threshold and uses the timestamp variance threshold for both timestamp
jumps and detecting timestamps).

The reason why this was done was because a timestamp jump could occur at
a higher threshold than the threshold used for detecting OS timestamps
within a certain threshold.  If timestamps got between those two
thresholds it kind of became a weird situation where timestamps could be
sort of 'stuck' back or forward in time more than intended.  Better to
be consistent and use the same threshold for both values.
Detect audio time values within OS time thresh.

If audio timestamps are within the operating system timing threshold,
always use those values directly as a timestamp, and do not apply the
regular jump checks and timing adjustments that normally occur.

This potentially fixes an issue with plugins that use OS timestamps
directly as timestamp values for their audio samples, and bypasses the
timing conversions to system time for the audio line and uses it
directly as the timestamp value.  It prevents those calculations from
potentially affecting the audio timestamp value when OS timestamps are
used.

For example, if the first set of audio samples from the audio source
came in delayed, while the subsequent samples were not delayed, those
first samples could have potentially inadvertently triggered the timing
adjustments, which would affect all subsequent audio samples.