Add CQ WW 160

[zcsahok]

Aiming to resolve #235.

First aligned the naming of spot.band with it actual use: it stores a band index (0,1,...), not a band (160,80,...). This was marked earlier in qso_from_spot(), where a temporary QSO is created for checking it for a new mult. Now qso->band contains the human readable band value (160,...).
Naming of freq2band() in bands.c was also fixed. (Sometime band index is referred to as band number, not easy to follow)

Next added setting of band value for a newly entered QSO. It is correctly filled in when reading the log, but was left out for new ones. Setting it in getexchange is just a stopgap measure: we shall in fact drop the global bandinx and use the one from current_qso instead.

[zcsahok]

Using simulated cluster spots:

• DL would be a new country
• TA has been worked already
• AB3AH is in PA, already in log
• AA3R is in DE, would be a new one

US states and Canadian counties are prefixed by their country prefix in order to separate them from DXCC prefixes.

After "working" AA1K (DE) AA3R is not marked as a mult.

@m5evt @N0NB may I ask you for a quick review?

[N0NB]

LGTM

I don't recall if there is a need for separate rules for US/VE versus DXCC entries. It has been a few years since I operated in that 'test and I probably won't in the foreseeable future for various reasons.

[zcsahok]

Thanks, Nate. The purpose of prefixing is purely technical, e.g. to be able separate Ohio from Finland.

[dl1jbe]

First aligned the naming of spot.band with it actual use: it stores a band index (0,1,...), not a band (160,80,...). This was marked earlier in qso_from_spot(), where a temporary QSO is created for checking it for a new mult. Now qso->band contains the human readable band value (160,...). Naming of freq2band() in bands.c was also fixed. (Sometime band index is referred to as band number, not easy to follow)

Thanks for sorting that out.

[zcsahok]

If there are no more comments then I'd merge this in.

[dl1jbe]

Looks good. Go ahead.