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)
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.
libbladeRF: Warning cleanup (Windows MSVC build)
libbladeRF: log_info() for flash operations

Update the flash operations for read/write/erase to be output with log_info
instead of log_debug since flash operations can take quite some time to perform.
libbladeRF: Adding newlines for info messages.
libbladeRF: Added backend to string function and wildcard backend str

bladerf_backend_str() may be used to retrieve the string associated with
the <backend> portion of a device specifier string (for use with
bladerf_open()).

It is now possible to specify "*" to denote "any available backend":
    bladeRF-cli -i -d "*:instance=0"
libbladeRF: Ensure async stream is running before submitting transfers

Erroneous behavior has been observed with GRC flowgraphs, where stream
buffers are submitted before the underlying async stream is running.

Although I have not been able to replicate this, this patch should
ensure that a buffer submission is delayed until after the async
stream has been initialized and is starting to run.
libbladeRF: Minor comment typo fix

This fix from 7548a8b69814d29e1b22d535ed4cbb7ccb81a022 had been
lost as a result of a rebase -- reintroducing it.