[musl] Add strict jemalloc dependency to deal with 1.2.1 breaking changes

Creating an issue in order to socialize this one and get some feedback before putting together a patch, because I'm not sure how folks will feel about it.

musl 1.2.1 introduces a significant breaking change to malloc() behavior which will cause a lot of headaches within Mono. Looking over it, this is a lot uglier than I expected, and 1.2.1 is strongly recommended due to the following described fix: "A major logic/synchronization error in lock skipping after a multi-threaded process returns to single-threaded state has been fixed". This specific issue was directly responsible for numerous hangs/stalls with _umtx spinning, often causing compile failures (CSC hang) or exhibiting during GC runs. The breaking change in malloc is described in the 1.2.1 release notes thusly: "This release features the new "mallocng" malloc implementation, replacing musl's original dlmalloc-like allocator that suffered from fundamental design problems. Its major user-facing new properties are the ability to return freed memory on a much finer granularity and avoidance of many catastrophic fragmentation patterns. In addition it provides strong hardening against memory usage errors by the caller, including detection of overflows, double-free, and use-after-free, and does not admit corruption of allocator state via these errors." Other projects and software have found that "mallocng" introduces a significant number of problems, particularly where GC is involved, but I haven't had much luck getting technical details on other breakage. However what is known is that musl 1.2.1 does Very Uncomfortable Things with malloc after fork, which obviously is going to cause problems.

My proposal here is to simply switch to depending on jemalloc in the autoconf run (basically throw error if it's unavailable on musl,) which is readily available as a package in most musl-based distributions and easily built on others. Previously, the musl maintainers have recommended this when 'oldmalloc' gave folks fits. This would insulate Mono and runtime from the breaking change in theory, but there is no guarantee that it will fully insulate it or continue to do so. And unfortunately, I simply do not have the time currently to do any sort of exhaustive testing or programming to work around it, and I'm uncomfortable with introducing a musl-malloc wrapper since that would then risk breaking everything <=1.2.0.