bladeRF-cli: remove bladeRF-flash mention from man page
README: update refs to bladeRF-flash (Fixes: #295)

Not 100% certain I like the answer to "If your board is stuck,"
but I do believe the 'recover' command is built for this.  Maybe
we need a wiki page or additional interactive help?
minor markdown error

Turns out that I can't see backticks with my monitor brightness set too low...
Updated "Quick Start" in top-level README.md

Links and firmware update information had become dated.
Additional top-level README.md touchups

Fixed a few formatting and typo issues.
Update CMake options in READMEs (#285)

Found all the cmake options I could, put them into the appropriate
READMEs.  There is some overlap between files but this may be a good
starting point at least.
host: Updated README.md content

Updated version numbers and project links.

Removed Debian/Ubuntu install commands; these are listed on the wiki. Eventually, we'll pull the wiki content into the official docs, and include similar instructions for a number of distros.
host: Corrected libusb ChangeLog link in README.md
libbladeRF: clarify doxygen instructions in README
host CMake: missing deps now FATAL_ERROR (#292)

In the event that BUILD_DOCUMENTATION is ON but Doxygen
or help2man are missing, or in the event ENABLE_LIBTECLA
is ON and libtecla is missing, raise a FATAL_ERROR and
abort CMake.

Since BUILD_DOCUMENTATION is OFF by default, and the existence
of libtecla determines the default for ENABLE_LIBTECLA, this
should have no impact for the casual "cmake .." user.
debian: update changelog w/ 2014.09-rc{1,2}
bladeRF-cli: Updated fallback cmd_help docs
libbladeRF: Removed old error tracking code and structures
libbladeRF: Moved "get sampling" implementation to lms.c
libbladeRF: Introduced thread-safety to a number of API calls

Top-level API functions now acquire a per-device lock before performing
control, programming, and low-level access operations. (Specifically,
these are the functions that manipulate the device handle and utilize
the FX3 <-> FPGA UART.)

Only these top-level functions shall acquire these locks; the core code
should be able to assume that locks are already acquired.

To alleviate confusion, functions that are *not* part of the API, and
therefore are safe to call within the core logic,  are stripped of the
bladerf_ prefix.
libbladeRF: [WIP] Began updating documentation wrt thread safety
libbladeRF: Hold control lock on get/set stream timeout fns
libbladeRF: [WIP] Additional API header updates and touch-ups
libbladeRF: [WIP] Acquire per-module locks on sync calls

Synchronous data transfer functions now hold a per-device-module lock
when executing to ensure these operations are carried out atomically.

The control lock is also held during sync configuration, as upcoming
changes to introduce metadata support will require flipping some config
bits on the FPGA during this operation.

Now that pthreads is a required dependency, use of the sync API is
is no longer marked optional in the libbladeRF build.
libbladeRF: [WIP] Hold control lock while (de)initializing stream