Move all converters to starch-based implementations

[mutability]

Short version:

• use starch to generate code to select from multiple converter implementations at runtime
• build implementations specialized for AVX2 (gcc autovectorization), NEON (intrinsics)
• provide default settings to select suitable implementations for armv6 (e.g. Pi 0W), armv7a with NEON (e.g. Pi 4), generic x86, and x86 with AVX2
• add a --wisdom option to allow overriding the defaults
• provide benchmark tools to generate a wisdom file specialized for the local machine
• add support in the dump1090-fa packaging to generate and read machine-specific wisdom from /etc/dump1090-fa/wisdom.local

Other stuff:

• tweak the zero offset of UC8 implementations slightly to better match how the RTL2832 behaves (the processed IQ data appears to be centered at 127.4, not 127.5)
• add converter tests to verify that they are producing correct output

Things that go faster:

• UC8 converters (e.g. rtlsdr path): x86 +10%, Pi 4 +100%, Pi 0W +50%
• SC16/SC16Q11 converters (e.g. bladerf path): x86 +500%, Pi 4 +450%

Things that go slower:

• Pi 0W SC16/SC16Q11 about 8% slower. This includes switching from the old limited-table-size implementation to a higher precision version that makes use of all bits (and we don't really expect to be running a 12/16-bit SDR on a 0W)

Things that are no longer supported:

• --dcfilter option. This could be reimplemented if there's demand, but it was always an experiment and I'm not sure there's actually any benefit to using it unless you're using a zero-IF tuner (and the commonly available zero-IF tuners can't tune to 1090MHz)

To simplify the build, the two dependencies (Google's cpu_features library and the starch infrastructure) have been copied directly into the dump1090 repo rather than being included by e.g. submodule reference.