Module system tweaks

This branch includes some improvements to the module system, which are of general interest I believe but will also make my forthcoming work on NixOS/nixops#78 cleaner. There are two fundamental user-visible changes here:

* By refactoring the merge code, it's now possible to use properties like `mkIf` inside of an option that is a container. So if you have an option `foo` that is `types.attrsOf types.int`, you can now have `foo.bar = mkIf cfg.useBar 2;` for example. Note that currently all post-systemd nixos setups have an empty `synergy-client.service` and `synergy-server.service` due to this not working as expected on master.
* The set of extra arguments passed to each module (e.g. `pkgs`, `modulesPath`, etc. that is currently passed everywhere in nixos) and the configuration knob to determine whether or not to allow definitions of options that aren't yet declared are now governed by internal options (`__internal.args` and `__internal.check`). The current interfaces in `<nixpkgs/nixos/lib/eval-config.nix>`/`evalModules` still work, but they use this under the hood. This makes the set of modules plus the version of `<nixpkgs/lib>` a full specification of the configuration, which is especially helpful in cases (like NixOS containers or modular nixops) where we want to make one config a submodule of a larger setup.

This introduces one backwards-incompatibility: Due to the change in how arguments are handled, modules shouldn't use the `pkgs` argument to get access to the module functions (`mkOption`, `mkIf`, `types`, etc) in `pkgs.lib`. Instead, they should use the `lib` argument that is passed to all modules, or they may result in an infinite recursion. This is already fixed for all in-tree modules, and unless you define options your personal configurations will probably not need to change, but if you run into an infinite recursion this is why, and the fix is to switch `pkgs.lib` to just `lib`.