Better naming `mkPerSystemOption`

[Atry]

mkPerSystemOption barely creates an option of deferred module for documenting purpose. Shall we rename it to mkDeferredModuleOption? Since it is general-purposed, shall we upstream it to nixpkgs?

[roberth]

Submodules also support the static merging of a module, so we should then also have mkSubmoduleOption, although submodules tend not to appear as the type of an option, but rather as a type argument.

It would be nice if the module system could cast function syntax in options to the right option type using the explicitly declared options. I feel like that's a lot to ask of the module system's already stretched syntax, but it is very ergonomic:

{
  options.perSystem = { config, lib, system, ... }: {
    # it's a module that's statically known, so has docs
  };
}

{
  options.services.nginx.virtualHosts = virtualHostName: { config, ... }: {
    # a NixOS nginx plugin
    # note that `attrsOf` already passes `"<name>"` for static purposes
  };
}

Arguments against:

• Learning curve
  1. More syntax to understand.
     • I find this argument questionable as the alternative has even more syntax.
  2. Not easy to go from the function shorthand syntax to an explicit option declaration.
• Opportunity cost
  1. unable to use functions in the option tree for something else.
     • I have no idea what that would be, and
     • the cost is small because explicit constructors could be used, such as mkOption.

Arguments for:

• Make "object oriented" module programming a lot more accessible.
• No need for mkDeferredModuleOption.
• We already do something similar for declarations into options that have a "bare" submodule type! Only for attrsets though: https://github.com/NixOS/nixpkgs/pull/156533

[Atry]

I think we should allow for merging an option with its default values, no matter what the type is.

[Atry]

I created #145 for now, as Nixpkgs right now has not yet supported directly declared bare deferred module.

[Atry]

Fixed in #145