This also makes "Unfree" and "Insecure" options homogenous.

This reverts commit 4ff1ab5.

This type was removed because it usually implies a bad design. However, since that
commit NixOS modules that can't live without it implemented several ugly ad-hoc
replacements for it while other modules that could make a good use of it
simply suffer. See the following commits.

... and change all of its uses.

Strangely enough, before this `_file` was in the public interface of the module
system while `file` was used internally by `lib.evalModules` code
after `lib.unifyModuleSyntax` was applied.

`_file` attribute was introduced in 800f9c2 but
I see no reason behind having "_" in the name there, all other attrs
processed by `lib.unifyModuleSyntax` keep their names between its input and output.

On the other hand, renaming `_file` into `file` makes `lib.unifyModuleSyntax`
accept its own output which is useful in cases when you want to modify
modules before shoving them into `lib.evalModules` but you don't want to duplicate
`lib.unifyModuleSyntax`.

The previous commit made it accept its own output, this also makes it
idempotent.

…g` of NixOS to it

This types `nixpkgs.config` of NixOS with `types.opaque` type and applies the
resulting evaluated value to the newly introduced `configs` argument of `pkgs`.

The new `configs` argument is like the old `config` argument (still available for
convenience) but a list.

This design was chosen because we can't just make a submodule out of
`pkgs/top-level/config.nix` in NixOS because

- firstly, we would have to duplicate all the magic `pkgs/top-level/default.nix`
  does to `config` in NixOS,

- secondly, in principle, we might not have all the arguments needed by
  `pkgs/top-level/config.nix` in NixOS because some of them can be
  computed internally by `pkgs` (this is not a problem now
  but it will be a problem in use-flags patchset that comes after), thus all
  of those computations will need to be duplicated too,

- thirdly, doing it this way keeps NixOS and pkgs separated, so that, in
  principle, one could replace NixOS with an alternative thing without duplicating
  all of the above once again and/or one could use separate module and type
  systems between NixOS and pkgs (`types.opaque` is trivial to
  implement in any type system and pkgs can use "types-simple" of NixOS#37252 today,
  if we were to wish it so).

Note that since this design removes the need to do any preprocessing of
`nixpkgs.config` in NixOS all the ad-hoc merging code was removed. Yay!

…ate it

This makes a removal of that attribute in ee1f34e
less violent. Now it can be properly deprecated using the new infra.

…s.config` of NixOS to it