libbladeRF: Added gain hotkey support to repeater test program

The numeric keys may be used to increase/decrease gains while running.
libbladeRF: Minor touch-ups in test_repeater

No need to use dummy variable with bladerf_init_stream as of commit
3e89a44f66239dfeb01ca6c5642e8c87c38cbbe7.

Reduced default sample rate to 1 Msps to avoid timeouts on Hi-speed
connections.
libbladeRF: Bumped patch rev (v0.13.2)

Changes include:
 - Repeater test hotkey support and minor fixes
bladeRF-cli: Bumped patch rev (v0.10.6)

Changes include:
    - Removal of bladerf_close() call after bladerf_device_reset() call
bladeRF-cli: Fixed unclear help text
libbladeRF: Documentation touch-up in bladerf_stream description

Noted that bladerf_enable_module() *must* be called prior to calling
bladerf_stream().
host: Added check for libc version

It's necessary to build with -lrt for libc < 2.17 when using
clock_gettime().
bladeRF-cli: Open binary sample files with "rb"

In Windows this caused the sample data to be corrupted when read.
libbladeRF: Re-implemented sync interface, updated API docs, renamed timeout function

The sync interface has been re-implemented atop the existing
asynchronous interface. This is currently opt-in and only enable when
pthreads support is enabled and available.

Some clarifications have been made in the API documentation,
specifically in the explanations of the various stream parameters.

The bladerf_set_transfer_timeout and bladerf_get_transfer_timeout have
been named more appropriately, as these control stream transfer
timeouts, as opposed to all transfers.
libbladeRF: libbladerf_test_sync runs full duplex
libbladeRF: Added loopback and clean SIGTERM handling to test_sync
libbladeRF: Moved internal sync handles into an array

This is a bit more consistent with what's already done with timeouts,
and is the preferred method of adding per-module items in the future.
libbladeRF: Include required OSX common/ directory items in build

The following items were missing from the changes introduced in commit
28ed798ce9b4a81f1bad6a6803a3d4dab3f146d3:

   - Add common/include/osx directory to libbladeRF include path
   - Add common/osx/src/clock_gettime.c to libbladeRF build
libbladeRF: Windows build fix for test_sync program

Build error results from treating warnings as errors, with possible overflow in 64 -> 32bit conversion.
libbladeRF: Added further clarification to (Doxygen) documentation
libbladeRF: Bumped minor rev (v0.14.0)

Note that this version introduces some reverse-incompatible changes
with respect to v0.13.z and earlier.

Changes Include:
    - Removal of bladerf_rx and bladerf_tx functions
    - Addition of a new synchronous interface that operates atop the
      asynchronous interface.
    - Renaming of stream transfer timeout functions

A friendly reminder - the v0.y.z series is officially "unstable."

Some further reverse-incompatible changes are expected to be made as
metadata support is integrated into libbladeRF. It is recommended to
avoid accessing/modifying metadata structures for the time being, as
these are subject to change.
libbladeRF: Fixed i386 build issue (libladerf_test_sync)

gcc-4.8.1 reports the following for FREQ_MIN:

... /test_sync/src/main.c:215:48:
error: this decimal constant is unsigned only in ISO C90 [-Werror]
libbladeRF: Added windows resource file with version information

A thank you goes out to LazyDodo for providing this patch.
libbladeRF: Clear sync buffer "in-flight" status when restarting stream

When restarting a stream, we assume in-flight buffers are lost. These
must be marked empty so they can be re-used.

Also in this commit:
    - Cleaned up unnecessary unlock, relock, unlock
    - Fixed return value check of pthread_cond_timedwait
libbladeRF: Only clear sync buffer status for TX items

When starting an RX stream, the first N buffers, where N is the number
of transfers, will be submitted when the bladerf_stream() call is made.

Therefore, it is incorrect to clear IN_FLIGHT status; this will result in an
assertion firing in the RX callback.

After looking into this, it's become clear that the sync interface does
not correctly handle the situation where the underlying async stream
starts up. Issue #229 has been opened to further track the associated
defect and resolution.