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.
libbladeRF: Typo fix for previous commit
libbladeRF: Improved range checks and associated documentation

API documentation changes:
    - Added min/max #defines for:
        RXVGA1, RXVGA2, TXVGA1, TXVGA2, sample rate, bandwidth,
        & frequency

    - Documented ranges and error/clamping behavior for:
        bladerf_set_sample_rate, bladerf_set_rational_sample_rate,
        bladerf_set_correction, bladerf_set_txvga1, bladerf_set_txvga2,
        bladerf_set_rxvga1, bladerf_set_rxvga2, bladerf_select_band,

Ensured the aforementioned functions clamp or return an error
for out-of-range input. The low-level functions have NOT been updated
for range checks. (e.g., bladerf_si5338_set_tx_freq).
bladeRF-cli: Enforce parameter ranges, help text touchups
libbladeRF: Corrected Windows header include for mingw compatibility

Thank you to sm5bsz for noting this issue and fix.
libbladeRF: Windows build fix

Declarations are required to be at the start of a scope.