CRAN R packages, rewritten

Packages for CRAN, the Comprehensive R Archive Network.
I have managed to compile 5000+ packages and masked ~300 packages which cannot be installed due to lack of dependencies or other reasons.

The files are organized as follows:

- cran-packages.nix: entry point
- sources.nix: source file definitions, auto-generated
- generate_sources.R: generator script for sources.nix
- generic-builder.nix: builder script, `R CMD INSTALL` with appropriate options and environment variables
- wrapper.nix: wrapper generator that combines R and CRAN packages
- packagesWithNativeBuildInputs.nix: additional `nativeBuildInputs` definitions for native library dependencies
- packagesWithBuildInputs.nix: additional `buildInputs` definitions for executable command dependencies
- packagesRequireingX.nix: list of packages requireing X to be running while installation
- packagesToSkipTests.nix: list of packages requireing special setup (e.g. MPI processes) for testing
- defaultOverrides.nix: other ad-hoc tweaks
- patches/: ad-hoc patches
- maskedPackages.nix: list of packages which cannot be compiled

I have checked that all packages are compiled with following `~/.nixpkgs/config.nix`.
```
{ 
  packageOverrides = pkgs: rec {
    rWrapper = pkgs.rWrapper.override {
      packages = map (name: builtins.getAttr name pkgs.rPackages) (builtins.attrNames pkgs.rPackages);
    };
  };

  ...
}
```

That does not mean that all packages do work properly; some packages may lack optional features, run slower than it can, or even worse crash with runtime error.

Note that Nix cannnot build a package with thousands of dependencies due to a limitation of shell script, so that building `rWrapper` with `~/.nixpkgs/config.nix` above result in `Argument list too long` after building all dependencies.

Unfortunately, some packages may update source archives without changing version numbers, so that installation may fail with a hash verification error.

Is this patch really required? It's quite common for configure scripts to refer to `/usr/bin/file` for some reason. We never patch those scripts, because it seems harmless to let that particular test just fail. Apparently, configure has other ways of determining the current $host other than `file` that it can fall back to.