Support multipliers per mode

[zcsahok]

A number of contests use multipliers by band and mode. Currently TLF supports only mults by band. The goal is to add support for mults by band and mode.

The basic idea is to extend the single band field in mults_t into a array band[mode] and in remember_multi() consider also mode, if needed.

[zcsahok]

Code is mostly ready, the harder part is now the configuration as the legacy boolean configs define the multiplier application mode implicitly: SECTION_MULT and SECTION_MULT_ONCE, etc.
SECTION_MULT_BAND doesn't look not too intuitive to me.
Maybe SECTION_MULT=BAND+MODE ? With SECTION_MULT=ALL being equal to SECTION_MULT_ONCE. Not sure.

[zcsahok]

Added the new BAND+MODE value to UNIQUE_CALL_MULTI and GENERIC_MULT.

The remaining configs are these booleans

config for per-band / once (or ALL)	related variables
WYSIWYG_MULTIBAND / WYSIWYG_ONCE	wysiwyg_multi / wysiwyg_once
SERIAL+SECTION / ---	serial_section_mult / ---
SECTION_MULT / SECTION_MULT_ONCE	sectn_mult / sectn_mult_once
SERIAL+GRID4 / ---	serial_grid4_mult / ---

The approach will be add for example WYSIWYG_MULTI with the same values are for GENERIC_MULT, but also keep the legacy configs. So for example WYSIWYG_ONCE will be equivalent to WYSIWYG_MULTI=ALL.
Variables have to be unified and changed to int to hold the MULT_xxx values.

[zcsahok]

Multiplier configs without "only" were kept as-is for the moment.

Updated pacc_dx and included a test for it.

[zcsahok]

Migrated IOTA to BAND+MODE mult setting.

[zcsahok]

Came across SERIAL_OR_SECTION: despite the promising description in the man page it does merely control the showing of the "section?" pop-up. I think it is safe to assume that the user is aware of the rules, so an extra question is just causes confusion.
Shall be fixed/improved separately.

[zcsahok]

I'd do man page update in a separate PR as we have #525 that also touches the man page.

[dl1jbe]

It is quite a bit of work to study so comments are preliminary.

• Base concept looks good. Mult handling seems also well implemented.
• A change of controlling keywords seems really needed. But i like that we harmonize the usage, e.g. 'GENERIC_MULT = NONE|ALL|....'.
• Do we have a way to announce the old keywords as 'deprecated' to motivate for migration?
• Just as a comment: I always have mental problems to connect 'ALL' to 'mults counts only once per contest'. The old 'ONCE' triggers more cells in my brain.

[zcsahok]

ALL makes me also think a bit more, than optimal. ONCE is definitely more intuitive.
(ALL comes from an earlier UNIQUECALL_ALL define)
Will add ONCE as an alternative configuration value for ALL.

Adding deprecation shouldn't be an issue, I have to just check how this affects the tests.

[dl1jbe]

Very well. Looks like it is ready to go in. +1

[zcsahok]

Changed ALLs into ONCE in rules.

Will address deprecation warning after the merge-in to handle it with a common function.