Rework flake and overlay structures

[oxalica]

• Drops flake-utils and follows https://github.com/nix-systems/nix-systems to allow overriding systems.
• Split the overlay interface from packaging/toolchain-selection logic.
• Avoid the need of import nixpkgs, as stated in Make it possible to use an already imported nixpkgs instead of using overlays #94

It would be good to export functions in lib.nix under lib flake output. But it's not easy since select* depends on unpacked manifests, which depends on pkgs. Using interface lib.select* = pkgs: <drv> would unpack manifests every time when called.

[emilazy]

Maybe you could expose lib.${system}.whatever and (lib.forNixpkgs pkgs).whatever? I'm not sure what the proper convention is for system-specific library code, though; I've run into it before and didn't manage to find any common pattern for it. (Of course nixpkgs just puts it all in legacyPackages).

[oxalica]

lib.${system}.whatever locks nixpkgs and makes it hard to override things like stdenv (which is already hard #70) without forking another nixpkgs. lib.forNixpkgs pkgs cause re-evaluation on every usage. I don't know a perfect interfact design yet.

Flakify everything has low priority now. I saw many people still like instantiating nixpkgs once at root-level pkgs = import <nixpkgs> { overlays = [ overlays-from-every-flake ]; } and use pkgs.some-package everywhere else, instead of typing inputs.some-flake.packages.${nixpkgs-pkgs.stdenv.hostPlatform.system}.some-package for each individual usage. Flake interface suits more one-off use case like "just run some version of rustc". When special extensions, configuration, or dependency overriding is required, it immediately gets more complex than the traditional overlays.

[emilazy]

Oh, I wasn't proposing dropping the traditional overlays for when you do want to mess with nixpkgs. But I try to avoid overlays as much as possible, so it'd work well for me to avoid the additional nixpkgs import.