Build static binaries on Linux using musl

[aykevl]

This PR adds support for musl-libc and uses it by default on Linux. The main benefit of it is that binaries are always statically linked instead of depending on the host libc, even when using CGo.

Advantages:

• The resulting binaries are always statically linked.
• No need for any tools on the host OS, like a compiler, linker, or libc in a release build of TinyGo.
• This also simplifies cross compilation as no cross compiler is needed (it's all built into the TinyGo release build).

Disadvantages:

• Binary size increases by 5-6 kilobytes if -no-debug is used. Binary size increases by a much larger margin when debugging symbols are included (the default behavior) because musl is built with debugging symbols enabled.
• Musl does things a bit differently than glibc, and some CGo code might rely on the glibc behavior.
• The first build takes a bit longer because musl needs to be built.

CGo doesn't work properly yet. Not quite sure how to best fix that without a somewhat big change. However, it's possible to work around that by first building a non-CGo binary and then building a CGo binary (the issue is that the libc is built after processing CGo headers).

[aykevl]

Note to self: this is failing on Windows and MacOS because the files src/exit/_Exit.c and src/unistd/_exit.c conflict with each other on a case-insensitive file system (only the base name is used, hence the conflict).

[aykevl]

This is now ready for review.

[aykevl]

From Windows (git bash shell):

$ GOOS=linux GOARCH=arm build/tinygo build -o test.elf ./testdata/cgo
$ scp test.elf ayke@raspberrypi:
test.elf                                                                                                                                  100%  147KB 781.8KB/s   00:00
$ ssh ayke@raspberrypi ./test.elf
fortytwo: 42
add: 8
myint: 3 5
myint size: 2
[...etc]

In other words, it's possible to cross-compile Linux binaries from Windows without installing any extra tools, even including CGo support!

[deadprogram]

Merge conflicts need resolution, please.

[deadprogram]

This PR has some failing tests now, @aykevl

[aykevl]

Yeah, there was a non-code conflict with #2135. Should be fixed now.

[deadprogram]

This seems good to me, but not really having used musl much, I am no authority. Anyone else like to comment on this PR before we merge it?

[deadprogram]

Oops, another merge conflict @aykevl

[aykevl]

I've rebased the PR again, thanks!

Now I can also see exactly how much space musl takes up:

$ tinygo build -o test.elf -size=full ./testdata/alias.go
   code  rodata    data     bss |   flash     ram | package
------------------------------- | --------------- | -------
     33    2696     108    1106 |    2837    1214 | (unknown)
   4518       8     240     588 |    4766     828 | C musl
    333      24       0       8 |     357       8 | internal/task
     58       6       0       0 |      64       0 | main
   1895     126       8      50 |    2029      58 | runtime
------------------------------- | --------------- | -------
   6837    2860     356    1752 |   10053    2108 | total

(I've already found a quick way to avoid ~1kB in musl, but that's for a separate PR. I'm pretty sure more can be avoided with some optimizations).

[deadprogram]

For sure a major accomplishment for cross-compiling. Now merging, thanks @aykevl

[QuLogic]

The first build takes a bit longer because musl needs to be built.

Can we pre-build it, like build-library for compiler-rt and picolibc, or does that not make sense?

[aykevl]

Can we pre-build it, like build-library for compiler-rt and picolibc, or does that not make sense?

Definitely. It's simply not implemented.
Note that the pre-built binaries are currently not working: they build for a configuration that doesn't exist anymore. See #2220. That's a bug that should be fixed.

[QuLogic]

Ah, perhaps that explains why even though I built the libraries into $TINYGOROOT, I still see the errors coming from ~/.cache/tinygo/....