Add support for Nix/NixOS

[JustAnotherCodemonkey]

Rationale

The build instructions in the README are not only not idiomatic to those who use Nix as their package manager, but do not work on NixOS itself. This PR addresses this by not only modifying the README for Nix/NixOS users but providing powerful utilities for Nix users, specifically, a Nix shell (shell.nix), a (maybe) Nix derivation (default.nix), and a (maybe) Nix flake (flake.nix). There may also be small things to tie up or patch as well before the PR is considered fully polished.

State of the PR

The PR is technically ready to merge now and it would add basic functionality with few/no loose ends. However, there are more features planned that have yet to be implemented. Some of them are considered "important" as they patch notable missing functionality for being able to create a Nix development shell (such as the ability to use the Limine bootloader, or the ability to build Theseus for other architectures). Others are considered "nice-to-have" and many of these will likely not fully make their way into this PR, and it may simply end up being Nix shells, with the other parts possibly coming in another PR. The desired features and their state of completion are as follows:

Important Features

• Rust toolchain (builder) expression for Nix
  • Support for adding arbitrary additional components to the toolchain with a default "development" toolchain extension for developing Theseus/for Theseus
• nix-shell for default building and running of Theseus
  • Support for non-x86_64 build hosts
  • Support for MacOS
  • Enhanced support for easy environment setup for using the Limine bootloader
  • Support for cross-compiling to aarch64
• Basic Nix flake providing a development shell with feature parity with shell.nix

"Would be Nice" Features

• Derivation for Theseus
  • Unified, ideomatic, and intuitive interface for the following:
    • Support for adding custom Application and Kernel crates
    • Support for control of "base"/"default" application/kernel crates (as in, ability to remove these components from the build)
  • Ability to control compiling and outputting/installing of individual, independently useful components of Theseus. (Attrset of derivations or big, complicated derivation that has lots of options to control build phases and outputs?)
    • Theseus ISO (output to $out/iso/ or $out/img/?)
    • Compiled Application and Kernel crates
      • Support for per-crate control of crate output installation
    • Individual crate sources?
    • Other intermediate build components and artifacts (which ones?)
• Full Theseus flake
  • Feature parity with default.nix derivation
• Toolchain builder expression
  • Support for easily adding MIRI to the toolchain

Considerations

• Since Theseus currently does not have a maintainer who is familiar with Nix and is still in a period of dramatic internal changes, any shells, derivations, and/or flakes need to be as resilient to changes in the build process as possible. This will mainly mean relying on the higher-level interfaces of the preexisting build system (i.e. the makefile) as much as possible, rather than using more internal Make targets, or recreating the actual build steps.

Important Questions to be Answered

• What byproducts of the build process can be considered independently useful? (i.e. what independent outputs should a potential derivation/flake support?)
• Are the builtin application/kernel crate sources useful for users developing for Theseus (such as independent app developers)? If so, what parts? (As in, what can be left behind?)
• What would a "unified, ideomatic, and intuitive" interface for customizing used crates look like?
• How should future changes to the build process that break these interfaces be handled?

[JustAnotherCodemonkey]

This is quickly becoming an issue. I've been relying on the Makefile, but for supporting non-x86_64 users and cross-compilation, it seems I will need to write a derivation (or maybe even just a flake) that re-creates the steps of the Makefile. This is really bad news to me, as the derivation/flake will need to be updated every time there is a change in the build process.