contracts RFC - alternate implementation using generated options

[KiaraGrouwstra]

This is a PR for contracts (NixOS/rfcs#189), using a fileSecrets contract as an example.
This iteration is similar to the earlier:

• Contracts RFC 189 #432529: like that PR made for a somewhat clean API, but the current PR addresses its docs build failure by avoiding config use within types
• Contracts rfc functions #485453: the conceptual basis for the current PR, tho the current one reconstructs options to make for a cleaner API
• Contract for files containing secrets #495303: similarly limited to fileSecrets, and built on top of by the current PR to address its duplication

Feedback welcome!
In particular:

• I'd be curious as to how unidiomatic the option generation looks - while I know types.optionType had a .merge, I tried to look for a method that might work with an API that's somewhat more plain.
• A move to lib helped build the docs by preventing types from depending on config, resulting in the current evalOption construct to be able to use the module system there still.

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/self-host-blocks-building-blocks-for-self-hosting-with-best-practices/26963/42

[KiaraGrouwstra]

while this PR was somewhat modest, i've since been on a more invasive reimagining of this making for a nicer API and accounting for use with modular services. i feel like, given the API changes, pushing that here would go against the more humble spirit of this PR, so i'll try and prepare a new one instead.

[KiaraGrouwstra]

as promised: #506343