libbladeRF: Added missing CALL_CONV's and corrected Doxygen annotations
libbladeRF: Removed duplicate code from sync_deinit()

The switch() statement here was a vestige from when there were
different condition variables (buf_produced/buf_consumed) that would
need to be passed to sync_worker_deinit().
libbladeRF: Set stream error code on unexpected libusb transfer error
libbladeRF: Propagate stream failure back to sync_rx/tx caller

The error codes from stream failures now work their way back to the
bladerf_sync_rx/tx caller.  Previously, such a failure would either
cause these calls to timeout (when a nonzero timeout_ms parameter was
provided), or (incorrectly) lock up waiting on a buffer while the stream
worker was idle.
libbladeRF: Reduced Error/Warning log level to Debug for lower-level errors

These messages don't mean much to folks not intimately involved with the
underlying libbladeRF code base, and the return codes already indicate
that a failure occurred.

Therefore, the Debug level is more appropriate here.
libbladeRF: Typo and formatting touch-ups in libbladeRF.h
linux driver: remove timeouts from read and write

read() and write() calls are now blocking calls
linux driver: fix TX routines

This commit improves buffer accounting and locking in the TX paths.
linux driver: fix RX routines

This commit improves buffer accounting and locking in the RX paths.
libbladeRF: Fixed minor comment typos
libbladeRF: correct bladerf_set_sampling RXVGA2-related log messages

bladerf_set_sampling - for internal/external sampling, the RXVGA2
    log warning messages were reversed (enable/disable RXVGA2)
hdl: add missing IQ calibration GPIO read/write in NiOS
libbladeRF: Refactored backend i/f to allow for new USB drivers

This work is largely based upon or directly from contributions by LazyDodo.

To allow for other USB drivers (e.g., native host drivers, the CyAPI) to
be more easily integrated, all driver-agnostic bladeRF<->USB code has
been moved to a generic USB backend. The intent is here is to decouple
bladeRF-specific logic from these USB "driver" interfaces to remove
unnecessary code duplication.

The contained changes include:
 - Splitting the libusb backend code into backend/usb/usb.c and
   backend/usb/libusb.c, and some cleanup in the moved code.

 - Removal of the flash_firmware() backend function. This is has been
   moved to flash.c, and is implemented atop the backend flash
   functions.

 - Removal of legacy support in the USB code. All legacy support
   is planned for removal and replacement with an appropriate
   error code to denote that a FW upgrade is required.
libbladeRF: Flash interface cleanup and flash-related API changes

Performed cleanup and reorganization of flash-related code. The following
items have been changed in the libbladeRF API:

 - Fixed "sector" vs "erase block" misnomer. While the SPI flash on the
   bladeRF has "sectors", these are not the units actually being used
   in the firmware to perform erase operations. As such, the API and
   underlying code has been updated to perform erases in terms of the
   "erase block" unit.

 - Renamed bladerf_program_flash_unaligned() to
   bladerf_write_flash_unaligned() for consistency.

 - Flash-related API calls now only return 0 on success, or a
   BLADERF_ERR_* value upon failure. They no longer return the number of
   bytes read/written/erased. This is intended to be more consistent
   with the rest of the API. The requested size of the read/erase/write
   is guaranteed to be performed at requested size, so returning a byte
   count merely complicates the API "contract" and offers no usefulness.

 - To erase the FPGA stored in SPI flash for autoloading, a new
   function, bladerf_erase_stored_fpga(), has been introduced. This
   replaces the use of bladerf_flash_fpga(dev, "X").

Internally, the following changes have been made:

 - All flash-related code has been moved to flash.c (e.g., from bladerf.c).
   This is part of the ongoing effort to move logic out of bladerf.c and
   into the associated module, with the intent of the bladerf.c
   "API top-level" of only acquiring a per-device lock (in the future)
   and delegate actions to the module implementations.

 - Backend flash operations are now in units of erase blocks and pages,
   to alleviate backend code needing to deal with conversions.
bladeRF-cli: Updated for flash changes in libbladeRF API

Made necessary changes for API changes and to correct the use of
"sector" vs "erase block."
bladeRF-cli: Use bladeRF_erase_stored_fpga() to disable autoload

The API has changed so that a filename of "X" does not kick off
an erase operation. The aforementioned function must be explicitly
called.
bladeRF-flash: Updated for flash changes in libbladeRF API

Changed text and code for "sector" vs "erase block" changes.
libbladeRF: Further revisions and API changes to the SPI flash interface

After further discussion, it was concluded that little benefit is gained
by providing byte interfaces to the SPI flash; users using this API were
already forced to be aware of page/eraseblock alignment, and would have
to be aware of the underlying flash memory map.

Therefore, the following API changes have been made:

 - bladerf_erase_flash() now takes an erase_block number and an
    erase_block count.

 - bladerf_read_flash()/bladerf_write_flash() now take a page number,
    and a page count.

 - The unaligned flash read/write functions have been removed. If users
   are going to be working at a low-level with flash, they'll likely
   want to manage the read-modify-erase cycles themselves.

Internal to libbladeRF, these changes have been propagated down to the
backend interface. Although the flash on the current bladeRF is only
a 4 MiB part, the types have been kept as uint32_t, to accommodate
any future HW changes.
bladeRF-cli: Updated flash commands for libbladeRF API changes

These commands now utilize the revised libbladeRF flash functions.

Page or erase-block alignment is checked when creating images, and
flash regions are explicitly erased prior to write.
bladeRF-cli: Do not reset device after flashing firmware

Resetting the device results in memory leaks, since the device handle
cannot be closed cleanly. The user is now instructed to power cycle the
device.

With these changes, command line FW flash should now operate the same
as the associated interactive mode command.