lib.types: add types.option

[KiaraGrouwstra]

i noticed that while we had a types.optionType, describing what goes into a module system type, we seemingly did not yet have a type to describe an actual module system option itself.
this change fills that gap.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/6555

[roberth]

🤨 With great power comes great responsibility!

Could you document this? And maybe add something that we generally prefer to avoid this type because it's a form of metaprogramming, making it harder to reason about a module.

(For context, not sure if that's applicable here, but I vehemently oppose the practice of "undocumenting" questionable features, which is subjective in the first place. If someone thinks it's questionable, that means they have something useful to say in the docs!)

[hsjobeki]

I wonder why a deferredModule is not sufficient? Encapsulating one or more options into a deferredModule, importing it along, where you need it?

[KiaraGrouwstra]

this type i'd hoped for for #500287.
y'all may well know more considerations from the module system perspective.