Add dogfood template (fix #104 and #121)

[Atry]

Motivation

• No great way to close over flake inputs #104
• Exposing a flakeModule that depends on other flake modules without defining in the same file #121

Testing

nix flake show

git+file:///Users/twer/github/flake-parts?dir=template/dogfood
├───apps
│   ├───aarch64-darwin
│   │   └───default: app
│   └───x86_64-linux
│       └───default: app
├───flakeModule: unknown
├───flakeModules: unknown
└───packages
    ├───aarch64-darwin
    │   └───hello_22_11: package 'hello-2.12.1'
    └───x86_64-linux
        └───hello_22_11 omitted (use '--all-systems' to show)

nix repl

Welcome to Nix 2.15.0. Type :? for help.

nix-repl> :lf .
warning: Git tree '/Users/twer/github/flake-parts' is dirty
Added 20 variables.

nix-repl> flakeModules
{ anotherFlakeModule = { ... }; dogfood = { ... }; hello = { ... }; }

nix-repl> 

[roberth]

Apart from the design issues, this would need testing and better inline documentation to explain succinctly the role of each file, etc. (Although don't invest in that before making sure everything works with tests, and maybe don't even test before resolving the double mkFlake design issue)
Besides the double mkFlake broken fixpoint, I have doubts about the module keys. A test should point out that that works, e.g. a test doing a double import and a test for disabledModules.

[roberth]

This breaks normal use of self. I don't think importing from self is important enough of a problem.
Making assumptions about the user's file layout is too magical. You are free to implement your own conventions using the specialArgs solution instead.

[roberth]

By conflating the published module and the current flake, you're causing users of the published module to export the published module. This is not right.

[roberth]

As mentioned before, this looks a lot like a broken implementation of fixpoint iteration, which is not feasible. In other words, references to the actual flake will not work as expected. We need to tie the lazy fixpoint knot, instead of providing a single fixpoint iteration step (out of a potentially infinite number of steps required).
I don't think this can be done without changing mkFlake.

[roberth]

Perhaps a way to work around the problem posed by graphs of public flakeModules is to set the module key by hand (EDIT: inside the module file, or by wrapping the module where you perform your local imports) for now.
I don't think we should bless that solution with a template until we've tried a mkFlake-based solution, but it seems that it would unblock your actual module implementation work for the time being.