Accept flexible frequency value strings

[nellump]

Currently, gqrx-remote.py only accepts frequency values specified without multiples (i.e., no "kHz", "MHz", etc.). Values may or may not include commas.

It would be nice if the user could specify frequency values with common multiple/exponent abbreviations, e.g. "kHz", "MHz", etc. The program would need to validate any user-specified values, and those values would need to be stored in the CSV file as they were input by the user, so that future presentation could preserve the user's format. Values would be converted to an unadorned format prior to passing them to the remote process (as the program currently does).

I'd be happy to implement this feature if it's considered worthwhile.

[nellump]

I have a first draft commit checked into my fork of gqrx-remote, on the branch "flexible-frequencies". From the commit message:

First take at making gqrx-remote abbreviation-aware.

DESIGN FEATURES

1. New bookmarks have their frequency value parsed and converted to
   standard SI-abbreviated notation (e.g., "100.1 MHz", instead of
   "100,100,000"). User-supplied frequency values can include SI
   abbreviations. They'll still be converted, if necessary (e.g.,
   "1100 kHz" will become "1.1 MHz"). A broad range of positive-valued
   exponents are recognized (kHz, MHz, etc.); case-insensitive (e.g.,
   "kHz" == "khz" == "KHZ").
2. Bookmarks have their values stored to CSV in SI-abbreviated
   notation. Values are not altered when read from the CSV file for
   display in the bookmark list.
3. Frequency values are converted back to unabbreviated values when
   being sent to a remote radio daemon.

AREAS FOR IMPROVEMENT

1. Users might not want their frequency values munged by the program.
   In the U.S. (and perhaps other countries), it is common to refer to
   broadcast AM stations' frequencies in terms of kHz. Currently, the
   program would convert "1100 kHz" to "1.1 MHz", which may be
   undesirable.
2. The program cannot handle unabbreviated frequency values that
   are not integers (e.g., it'll complain about "100.3").
3. Some parts of the program could really use unit tests (the
   pretty-print subroutines, especially).

This commit is functional, but not complete. I'm sure there are still
bugs yet to be discovered.