debian: fw 1.8.0, fpga 0.1.2
libbladeRF_test: Added common cmdline arg handling and device config

Most of the libbladeRF_test items contain their own command line
argument handling, yielding repeated code and inconsistent invocations.

This commit introduces common command-line argument handling and device
configuration for the most used device parameters.

Future patches will migrate the tests over to using this functionality.
New tests should use this immediately.
libbladeRF_test: Added frequency hopping test

This test is intended to help investigate reported issues involving
device lock-ups when changing frequency while samples are streaming.
libbladeRF_test: Addressed uninitialized variable warning (Clang)

'status' would not be initialized if t->num_iterations < 0. This shouldn't
happen anyway, but it has been fixed to keep the static analysis reports
free of false positives.
libbladeRF_test: Fixed erroneous/missing assignments in test_common.c
libbladeRF_test: Fixed option string for test_freq_hop
libbladeRF_test: Fixed Windows build issue introduced in d990841
host: Corrected description of file copy operation
libbladeRF: Do not crash upon out-of-order transfer completion callbacks

The assert() failures in Windows from issue #351 appear to be the result
of libusb transfer completion callbacks arriving out of order. This
seems to happen pretty reliably after an event that momentarily spikes
CPU load when using higher sample rates.

This has been reproduced on Windows 7 and 8.1 with libusb 1.0.19. The
Cypress backend is not affected.

When we expect that transfer number N to be available next, I'm seeing
that transfer [ (N+1) % num_transfers ] is actually coming back as the
next available transfer.

For example we get transfers ... 6, 7, 8, 10, 9, 11, 12 ...

This patch is a band-aid to allow us to just use the next available
transfer, instead of assuming which transfer it will be.

While this should keep things running instead of grinding to a halt [1],
it does *not* address the underlying issue. Out-of-order transfer
completion indicates users may get buffers out of order, which is
unacceptable. As such, we will need to keep digging further, and I
will register a new issue regarding libusb giving us out-of-order
transfer callbacks.

[1] Arguably, a transient bad buffer is better than an entire
    application crashing, now that we're aware of this.
doc: Added "bladeRF Bug Reporting Guide"
doc: Added "bladeRF Style and Coding Conventions" document
doc: Added "bladeRF Patch Submission Guidelines" document
doc: Fixed GitHub-specific code snippet issue

The code snippet in the coding syle & guidelines doc was not rendering
properly on GitHub -- it was truncating the snippet.

This has been fixed and the C language has been specified for syntax 
highlighting.
doc: Fixed what would be a potential bug in an example snippet
doc: Added GitHub syntax highlighting for VHDL snippet in style & conventions doc
doc: Fixed whitespace issues in submitting_patches.md
doc: Added "bladeRF Version Change Checklist"
doc: Added "bladeRF Test Checklist"
doc: Fixed "checkbox" syntax version_change_checklists.md

This is a GitHub-specific Markdown variant that renders "* [ ]" as
a nice little checkbox, but isn't terribly annoying otherwise.