very refactor: continuing sodiboo's work

[epireyn]

hello. i have decided that This is an arbitrary point in time at which i want to make relatively major internal structural changes to this flake.

so far, i've started with refactoring the settings module into a directory with a bit cleaner organization. notably, all of the rendering logic is now right next to the option definitions. i also made it internally use the "new" KDL representation from NixOS/nixpkgs#426828, which also means ditching the pure-nix serializer i had previously written.

because niri v25.11 has config includes, a lot of the config is now partial. so, there will be less "default values" hanging around of things you didn't configure. i also did some web development and made generated documentation for the settings that feels way nicer. check out what i've got so far

next up, i need to rework the modules for integrating those settings into a NixOS and/or home-manager configuration. in doing so, i'll finally deprecate the current niri-flake.nixosModules.niri properly, which has been a long time coming. i've already begun that work slightly by factoring out the binary cache to its own module. i also want to write a bit more welcoming documentation that's less out of date and less shaped like this mess. the current documentation is half-outdated and Slowly Rotting, most of it was written before NixOS even had a module to install niri. i will write new documentation that's better™, and accurately describes how i think niri-flake is best used today.

i'll probably also be implementing the rest of the settings from v25.11. that is, i hope that this will close sodiboo#1493. probably, i'll end up fixing a bunch of other issues and superseding some other PRs along the way. for instance, the new organization of the settings is already much more convenient to consume without flakes, and i'm hoping to make all niri-flake functionality work that way. that is, i'm trying to fix sodiboo#1089.

and in general, until i'm done with this, i'm hesitant to merge any other PRs, because at best they'll cause annoying merge conflicts with this branch, and at worst they'll be made irrelevant by things i was going to do anyways or things that have changed enough to need to rewrite the functionality anyways.

yes, i know there are a bunch of open PRs. and to be honest, i haven't had the energy to look at most of them. i probably won't look at most of them either, until i'm done with these changes.

Upstream: sodiboo#1548