Missing ports for full self-hosting

[Dennisbonke]

For managarm to become fully self-hosting, the following ports are missing (incomplete list)

• autoconf, blocked on a working perl port
• automake, blocked on a working perl port
• libtool
• m4
• patch, ported, seems to work
• git, blocked on networking and /dev/null support
• mercurial, blocked on networking and more python support
• cmake
• wget, ported, seems to work decently, blocked on further tcp changes for now
• curl, ported, but needs more work
• grub, to produce an image
• subversion. as preliminary support for subversion is pending in xbstrap, and pcre will move to an subversion repo, this tool is needed to allow xbstrap to build pcre
• bison, many build systems invoke bison at some point
• flex, as said with bison, flex is used in some build systems
• texinfo, if we want to be able to produce documentation, texinfo is a must. This is blocked on a working perl port
• rsync, to copy the contents of the sysroot to the image, rsync is used
• cpio, the initrd that managarm uses is compressed with cpio

Furthermore, the following ports need attention before self-hosting can be achieved (incomplete list)

• make, needs extensive testing
• perl, segfaults when running, a fix is in development for this (this has been fixed by disabling locale suppport. Now perl is awaiting pthread_atfork() unimplemented mlibc#101 and sigsetjmp() / siglongjmp() unimplemented mlibc#102). Basic Perl programs can now run.
• ncurses, this really needs to produce shared libraries
• bzip2, crashes due to missing utime() (this has been fixed in current mlibc master, just awaiting a small build fix)
• xz-utils, crashes due to missing printf() specifier
• gettext, if we ever want to handle localized messages in applications, gettext at build time is a must, furthermore, support for this in mlibc needs to be added. A basic port is available, but untested and unused at this time

For proper self-hosting, we also need some extra support in managarm itself (incomplete list)

• Support for loopback devices, the current image generation process either uses libguestfs or loopback devices, the latter should be easier to implement then libguestfs

This list is an addition upon #39 and #30