feat: support cross compiling libcartesi as a static library

[edubart]

Included changes:

• introduce the TARGET_OS make parameter, to allow cross compiling to other OSes
• make termios.h non-mandatory to compile libcartesi.a when defining NO_TERMIOS, because WASI SDK target has no support for it
• build libcartesi.a static library
• remove the use of std::filesystem from libcartesi.a, because WASI SDK target has no support for it
• refactor object file lists in the makefile, to include only what it should in the static library
• build and install libcartesi_jsonrpc.so and libcartesi_jsonrpc.a, the code was there, but it was not being compiled or installed
• removed all uses of rpath and patchelf, now all executables and shared libraries are statically linked
• libcartesi.so still is being built, but is not being linked by anyone, people will be able to choose to link to libcartesi.so or libcartesi.a
• refactored make install to install and strip properly the binaries and libraries
• some makefile cleanups
• added possibility to compile libcartesi.a without mmap
• isolated all OS related functions in os.cpp file with automatic detection of supported functions when targeting WASI or Windows
• added ways to disable all OS function implementations with -DNO_TTY for example, in case the target doesn't have an OS supporting that API
• the flags -std=c++17 -pedantic was replaced with -std=gnu++17 -Wpedantic. Because the old flags actually disabled some POSIX functions (such as mkdir and gettimeofday) in some toolchains (such as Cosmopolitan or DJGPP for DOSBox).
• the privileged and PAGE_SIZE keywords is a define in some toolchains and gave compile errors, so I renamed them
• added make bundle-boost, for making easy cross compiling libcartesi with other toolchains
• allow compiling libcartesi.a in standalone without need to have GRPC or Lua installed in the system, added instructions to README, this important when only wanting to cross compile with other toolchains
• refactored Makefile to remove some :=, to invoke some shell commands which depends on system having protobuf, grpc, lua etc only when really needed by a job
• removed CM_API from machine-c-api-internal.h functions because those APIs should not be exposed in the public C API
• added support for compiling libcartesi in systems without threading support with make nothreads=yes
• fixed issues for building on MacOS with homebrew with old clang toolchain

After this PR, it is possible to compile a libcartesi.a for WASM using two different toolchains (as long you do make bundle-boost before):

With WASI SDK toolchain:

make -C src -j8 release=yes \
  TARGET_OS=Linux \
  CC=/opt/wasi-sdk/bin/clang \
  CXX=/opt/wasi-sdk/bin/clang++ \
  AR="/opt/wasi-sdk/bin/llvm-ar rcs" \
  libcartesi.a

With Emscripten toolchain:

make -C src -j8 release=yes \
  TARGET_OS=Linux \
  CC=emcc \
  CXX=em++ \
  AR="emar rcs" \
  libcartesi.a

With GCC RISC-V toolchain (for running a cartesi machine inside itself, yay):

make -C src -j8 release=yes \
  TARGET_OS=Linux \
  CC=riscv64-linux-gnu-gcc \
  CXX=riscv64-linux-gnu-g++ \
  AR="riscv64-linux-gnu-ar rcs" \
  libcartesi.a

With mingw-w64 toolchain (for Windows build):

make -C src -j8 release=yes \
    TARGET_OS=Linux \
    CC=x86_64-w64-mingw32-gcc \
    CXX=x86_64-w64-mingw32-g++ \
    AR="x86_64-w64-mingw32-ar rcs" \
    MYSOLDFLAGS="-llua.dll -static" \
    libcartesi.a cartesi.so

NOTE: TARGET_OS=Linux and cartesi.so seem suspicious, but is the correct way to cross compile to Windows build for now.

I also tested libcartesi of this PR to compile with the following platforms/toolchains:

• FreeBSD with its GCC toolchain
• DOS with DGJPP toolchain
• Windows with Visual Studio clang toolchain
• Comopolitan libc with its cosmocc toolchain (after removing exceptions)
• MacOS 10.15 x86_64 with clang 12 + Homebrew
• Android

[diegonehab]

What "crazyness" required this?

[edubart]

Some systems that I cross compiled (such as DOS), did't have all POSIX functions available when using -std=c++17, it didn't enable non standard C APIs, such as gettimeofday, mkdir, and others, because they are not in standard C. I think some systems are free to disable POSIX APIs with -std=c++17.

So having -std=gnu++17 is more friendly for cross compilation, another option could be removing -std= and let use the default one.

[diegonehab]

In an ideal world, we would change this flag only on os.cpp, right?