build: add initial nix build system

[pauliesnug]

why?

nix is a language-agnostic build system that is purely functional;
a "package" is a function which accepts inputs (src code, config, etc)
and produces an output (binaries, a jarfile, documentation, anything)

one benefit of this is reproducibility. if you specify your inputs precisely,
and take care not to introduce impurities, you will receive byte-for-byte,
the exact output as someone else running the same function over the
same inputs.

gradle is not a functional build system. oneconfig produces highly variable
outputs depending on a host of impure inputs, including:

• the jvm hosting the build
• the gradle install running the build
• usage of dynamic version constraints
• snapshot dependencies
• environment vars and cli options
• artifacts cached on the system hosting the build
• gradle wrappers

by using nix we can solve these problems by using it to control
the inputs we use when building polyfrost projects. this is useful
for both development and packaging.

when run on oneconfig (hopefully), it will record all dependencies
for both the build environment and the project, and provide a nix
expression to run the build. the build itself is run in a secure sandbox,
where only content-tracked network requests are allowed to fetch
dependencies, and a local maven repo is created on-the-fly to
host the dependency artifacts somewhere gradle can resolve them
(using nix's package management)

we can use this to:

• create isolated, secure, fast, and reproducible dev envs that work anywhere
• reduce or eliminate flakiness and maintenance headaches from developers
  using/building polyfrost projects and CI/CD pipelines
• distribute a recipe which can reliably build a Gradle project (e.g. if we want
  to distribute a project on a package manager)

uninix gradle and the implementation isnt fully done yet (hence the draft) but i think this would be cool to implement in polyfrost projects.

[pauliesnug]

whu

[xtrm-en]

👍

[pauliesnug]

@xtrm-en thanks cutie