store settings in firmware

Many of the functions in libhackrf affect the state of the hardware without those settings being stored in RAM by the firmware. For example, hackrf_set_lna_gain() passes a numeric setting to the HackRF which the firmware converts to a setting for the MAX2837. The firmware then stores the value only in a register of the MAX2837.

Retrieving such values from the registers of various components is non-trivial and has not been implemented. In order to facilitate the creation of "get" functions to complement "set" functions (#129) and potentially for other purposes, it would be helpful if the firmware stored such configuration settings in RAM when those settings take effect. Providing the ability for the host to retrieve the settings would enable user software to report the state of the hardware (#578).

In some cases, user-requested settings may not be precisely honored by the firmware, but we currently provide the user no way to confirm this (#524).

I propose a new static settings structure in firmware/common/settings.c that stores settings configured by all of the following libhackrf functions:

hackrf_set_amp_enable
hackrf_set_antenna_enable
hackrf_set_baseband_filter_bandwidth
hackrf_set_clkout_enable
hackrf_set_freq
hackrf_set_freq_explicit
hackrf_set_hw_sync_mode
hackrf_set_lna_gain
hackrf_set_operacake_ports
hackrf_set_operacake_ranges
hackrf_set_sample_rate
hackrf_set_sample_rate_manual
hackrf_set_txvga_gain
hackrf_set_ui_enable
hackrf_set_vga_gain

Additionally we should move transceiver state and sweep mode state into this structure, and we should follow this pattern for future firmware features that are configured over USB.

Potentially this structure could be used in the future to provide a way to load and store all settings at once.