Regression tests in make check, sanitisers in CI

[TheOneric]

UBSAN seems to have found something in our UWP build on regression/karaoke/357-k-and-kf-desynced.ass, thus the UWP failure. As MSys2 doesn't ship the supporting UBSAN library, there's no report indicating what the problem is though (using -fsanitize-undefined-trap-on-error will cause SIGILLs (for Windows exit code 132) when something is found and allows the sanitiser to function without the library).
It would be good if someone can look into UBSAN’s findings; I don't see a way for me to investigate this myself. If nobody can, I'll probably just have to disable sanitisers for UWP.

[TheOneric]

If someone with a Windows dev and/or debugging setup at hand wants to take a stab at the UBSAN findings, the options are:

• using a debugger to locate roughly where the UB is located and then step through that part to find out the exact location (won't directly show why it is UB, but doesn't require libubsan)
• Obtaining libubsan somehow.
  • search results suggests MSVC has UBSAN and libubsan, but I don't know if the lib is compatible or if compiling with MSVC finds the same bug(s).
  • At least on glibc Linux, building GCC from source (including bootstrapping) also yields a libubsan binary.
    As UBSAN should afaik support WIndows, it seems plausible building GCC from source in MSys2, will also yield a suitable libubsan — if there isn't some incompatibility with UWP...
    Building with bootstrapping may take an hour or more depending on machine and for me ~8GiB of object files were created (+2GiB for the sources and git repo).

  # Tested on glibc-Linux with e32ca426242f0e3c650f3122342792ad42255511
  git clone https://gcc.gnu.org/git/gcc.git gcc
  cd gcc
  autoreconf -ivf .
  ./contrib/downoad_prerequisites
  cd ..
  
  mkdir gcc-build
  cd gcc-build
  ../gcc/configure --enable-languages=c --disable-multilib
  make -j "$(nproc)"
  # for me the uninstalled lib binaries were located at
  #   x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.*

---

@rcombs: rebasing #636 on master should now reveal the mentioned linking issues in the CI’s ubuntu+gcc build (clang seems to pull in pthreads automatically?)