Expand C lib support using `musl` implementations

[robdockins]

MUSL is a smallish libc implementation for linux-based systems. We could probably make pretty good progress on expanding the amount of libc coverage we support by simply grabbing implementations piecemeal and linking them into bitcode files, similar to the way we link in support for libcxx. Obviously, anything that boils down into actually syscalls wouldn't work, but there are a lot of utility operations that simply invoke other primitives or can be directly implemented.

MUSL is nice for this purpose because it is released under an MIT license, which is highly compatible with our own ecosystem.

[langston-barrett]

As @travitch mentions on #911, another approach would be to write our own versions in C (or do so in cases where MUSL's implementations are unsuitable for whatever reason).

I think this certainly sounds like a good way to get more coverage, though there might be a complexity trade-off in that we'd have to worry about things like:

• Do we store the C sources or the compiled bitcode in revision control?
  • If the former, when does it get compiled and packaged for releases? Or is Clang a runtime dependency of Crucible tooling?
  • If we store bitcode, are we willing to store binary blobs, or do we store human-readable .ll files, and then ask those same questions about when it gets assembled? (Or can llvm-link handle .ll files?)
• Are we willing to make llvm-link a runtime dependency of Crux and other tools? (c.f. SMT solvers, the other big runtime dependency)
• How will we deal with differening LLVM versions between:
  • The libc bitcode
  • The program's bitcode
  • Whatever llvm-link is available

Some of these questions might have already been answered in the context of the libcxx bitcode.

[langston-barrett]

Yet another possible approach would be to write overrides in the Crucible-LLVM S-expression syntax, which avoids many of the downsides mentioned in my last comment.