Porting mimalloc to Solo5

[Solo5](https://github.com/Solo5/solo5) is a sandboxed execution environment primarily intended for, but not limited to, running applications built using various unikernels (a.k.a. library operating systems).

I have a local branch (against `dev`) with a (mostly) complete port, but there are a few things I'd like to discuss before making a proper PR.

- Solo5 is a "bare" target. At a program's entry point, it provides a [flat memory range](https://github.com/Solo5/solo5/blob/c79d304d4896da6e8b42e6c76285c76a4e4e0e3a/include/solo5.h#L100-L106) in which both the call stack and the heap will live. For now I require the user to reserve memory manually using a static stack size (i.e. `mi_manage_os_memory(info->heap_start, info->heap_size - STACK_SIZE, [...])`) before doing any allocation, making `_mi_prim_alloc` always return `ENOMEM`. However, in OCaml's Solo5 toolchain (where they use `dlmalloc`), they implement a ["dummy" `sbrk`](https://github.com/mirage/ocaml-solo5/blob/ad37491b051d47d782d1f73bc447ff1e7a764bcb/nolibc/sysdeps_solo5.c#L119-L135) which dynamically checks if the heap gets too close to the call stack. My opinion is that a static stack size should be fine since processes running on an ordinary OS usually also get a limited stack. It also makes the code simpler.

- Solo5 doesn't provide a standard C library. The headers (`errno.h`, `string.h`, ...) and functions (`abort`, `mem*`, ...) mimalloc expects must be come from somewhere. I think the user (not mimalloc) should be responsible for providing such a library. For example, I'm interested in writing unikernels in Koka which requires a lot more from the standard library, and splitting a standard library between different projects depending on their particular needs doesn't make much sense to me.

- [The Solo5 toolchain's `cc`](github.com/Solo5/solo5/blob/main/toolchain/cc.in) is just a wrapper around the host system's `cc`. For now I detect that we're building for Solo5 with `defined(__STDC_HOSTED__) && __STDC_HOSTED__ == 0`, which is set that way because of the `-ffreestanding` flag. This is not very robust, we have to check for Solo5 before any other platform (since `cc` will still define platform-specific constants for the host, like `__OpenBSD__`) and maybe we'll want to add other freestanding platforms in the future.

I'd be happy to read some opinions. It's fine if this isn't wanted in the main repo, I just wanted to put it out there if anyone's interested.

Start by reading Solo5's include/solo5.h memory-range definition and toolchain/cc.in, then compare the linked OCaml sysdeps_solo5.c sbrk implementation. The open questions are stack and heap management, freestanding standard-library responsibilities, and platform detection. Done would be an agreed design and a proper porting pull request, but this issue does not define those decisions.

Written by the indexing model from the issue text.