Improve APO/GraphicEQ import/export

[Digitalone1]

• Added gsettings key range check for double/float values inside APO/GEQ import. I don't like this, the functions are now very complex because of this implementation, but it's the only way to make a check on valid values. Besides I suspect native gsettings is only emitting a warning on out of bounds values, but on Flatpak it may crash directly because the settings engine is different. If this is the case, those key checks will fix a big issue on that platform.

• Since band_width affect the spectrum of the selected band depending on the filter type chosen, I reset it at the default on APO/GEQ preset import. Maybe this value should be properly calculated on every filter, but we don't know how to do it. So at the moment the best thing to do is to reset it to the default, avoiding to change the result depending on which previous value the user set.

• Reset band_width also inside on_calculate_frequencies. This seems a good thing to do since band_width affects the band spectrum, but maybe I could be wrong here. @wwmm What do you think?

• Reset input-gain on GEQ import. APO import always sets the preamp (0 db if not specified). But if we import an APO preset with a specific preamp and then import a GEQ preset, we retain the previous input gain, which I think it's not what we expect. GEQ does not have a preamp control, so I assume it's always 0 db by default.

• Improved APO preset parsing. The best thing to do is to follow this algorithm: https://github.com/lsp-plugins/lsp-plugins-para-equalizer/blob/master/src/main/ui/para_equalizer.cpp#L1502 - Which sets a specific quality or frequency on certain filters, no matter which is the value inside the preset file.

• Added the Band-Pass filter in the APO preset parsing. This is not present in the LSP algorithm, but we may add it anyway. @wwmm Any suggestion here?

• EasyEffectsToApoFilter and ApoToEasyEffectsFilter converted to maps. There's no real reason to use them as unordered maps. Besides the EasyEffectsToApoFilter was specifying the same LSP EQ filter multiple times which is useless. It makes sense to traslate LSP filters only to APO filters that have center frequencies.

• In APO export, write the gain value only for filters that need it. See APO config documentation: https://sourceforge.net/p/equalizerapo/wiki/Configuration%20reference/#filter - The gain is mandatory only for Peak, Low-Shelf and High-Shelf filters.

• Use tags::equalizer namespace on the entire files so we don't have to specify it multiple times.

• Added number label on top of each bands inside Equalizer UI. This may seem unnecessary, but I think it's very useful. When I was testing the import feature, comparing APO presets bands with the results in the UI was not so easy because sometimes I had to count the bands. Indeed if the user has a big number of bands, looking at one in the center it's not easy for them to know which is the number of the chosen band. With a label on top, it's more straightforward.

And at the last I'd like to point out that I'm a bit skeptical on the use of band-mute in APO import. At the moment the APO OFF value sets the band-mute, but is it really the same? OFF means the band is not processed, so we still hear it, right? Which is different from the muting which is just emitting silence, I guess? Maybe like band gain to -infinite. Maybe it should be better to set band-type on Off when APO OFF is specified. The problem seems that APO does not have a concept of "muting the band". @wwmm What do you think?

[github-actions[bot]]

Workflow failed, but the following artifacts are still available for this pull request:

• easyeffects-archlinux-merge-d2e4bb2d4-into-5f207c83f-x86_64.zip
• easyeffects-flatpak-merge-d2e4bb2d4-into-5f207c83f-x86_64.zip

[wwmm]

Reset band_width also inside on_calculate_frequencies. This seems a good thing to do since band_width affects the band spectrum, but maybe I could be wrong here. @wwmm What do you think?

It has been so long since I thought about this LSP band_width parameter that I do not remember anymore exactly what it is doing. But as far as the on_calculate_frequencies code goes I think it is fine to reset it. It would only be a problem if the bad)width parameter conflicted with the quality value calculated inside on_calculate_frequencies. But I think this was not the cause.

The problem seems that APO does not have a concept of "muting the band". @wwmm What do you think?

Hum... I think that we probably should set them to OFF.

[Digitalone1]

@vchernin can you please check this PR importing the APO preset here on Flatpak and see if something weird happens? Thanks.