Re-imagined standalone mode (`nixvimConfig`)

[MattSturgeon]

Currently, standalone mode is a function that takes a nixvim module and optionally a nixpkgs instance, then returns a wrapped neovim package.

I won't go over all the pitfalls of this approach here, but some are covered in #2186.

In contrast, both nixos and home-manager have the concept of a "configuration". A configuration is simply the result of calling lib.evalModules with nixvim's modules and a user's nixvim modules; specifically an attrset with the form:

{
  _type = "configuration";
  options; # options, as passed to modules
  config; # config, as passed to modules
  _module; # internal module config, e.g. _module.args
  extendModules; # a function to re-evaluate with additional modules
  type; # a submodule option-type, can be used instead of `types.submodule`
  class; # usually null, a nominal module type. When non-null, it is used to filter imported modules
}

Incidentally, extendModules is a function similar to evalModules itself, taking modules, sepcialArgs, and prefix as optional args. It returns a new configuration, similar conceptually to our current <nixvim>.extend function.

Tools like nixos-rebuild and home-manager simply build <configuration>.config.system.build.toplevel; similar to our finalPackage this is just a package-type module option.

I propose that (at some point after 24.11) we begin promoting the use of our evalNixvim wrapper function as an alternative to the current standalone wrapper (makeNixvim).

Users would consume this by having a nixvimConfigurations flake output, and/or a nixvimModules flake output for un-evaluated modules.

They can then re-use nixvimConfigurations.<system>.<name>.config.finalPackage a in their flake packages output and/or in their other configuration modules (e.g. nixos environment.systemPackages).

One thing that feels a little clunky here is nixvimConfigurations.<system>; historically a "configuration" would be system-specific. Although in theory there's nothing stopping you from having perSystem nixos/home-manager configs somewhere in your flake outputs...

We may also want to adopt a similar option structure to nixos; putting our build outputs under the config.build.* namespace instead of at the top config.* level (done in #2306).

I think we should also think about making our lib functions more accessible too; in particular having them not need to be system/pkgs specific would allow our lib flake output to be used as: inputs.nixvim.lib.nixvimConfiguration; which is much more ergonomic than inputs.nixvim.lib.<system>.nixvimConfiguration. See #2186.