Rework the knot-tying code for defining Haskell packages.

The existing knot-tying code I felt was a bit incoherent with result, finalReturn, self, refering to different various forms of the "haskellPackages" value and often
different forms in the same place.

This commit instills some object-oriented discipline to the construction of hasekllPackages using a small number of fundamental OO concepts:

* An class is a open recursive function of the form (self : fooBody) where fooBody is a set.
* An instance of a class is the fixed point of the class.
  This value is sometimes refered to as an object and the values in the resulting set are sometimes refered to as methods.
* A class, foo = self : fooBody, can be extended by an extension which is a function bar = (self : super : barBody) where barBody a set of overrides for fooBody.
  The result of a class extension is a new class whose value is self : foo self // bar self (foo self).
  The super parameter gives access to the original methods that barBody may be overriding.

This commit turns the haskell-packages value into a "class".

The knot-tying, a.k.a the object instanitation, is moved into haskells-defaults.  The "finalReturn" is no longer needed and is eliminated from the body of
haskell-packages. All the work done by prefFun is moved to haskell-defaults, so that parameter is eliminated form haskell-packages.  Notice that the old prefFun took
two pameters named "self" and "super", but both parameters got passed the same value "result".  There seems to have been some confusion in the old code.

Inside haskell-defaults, the haskell-packages class is extended twice before instantiation.  The first extension is done using prefFun argument.
The second extension is done the extension argument, which is a renamed version of extraPrefs.

This two stage approach means that extension's super gets access to the post "perfFun" object while previously the extraPrefs only had access to the pre "prefFun"
object.  Also the extension function has access to both the super (post "perfFun") object and to self, the final object.  With extraPrefs, one needed to use the
"finalReturn" of the haskell packages to get access to the final object.  Due to significant changes in semantics, I thought it best to replace extraPrefs with
extension so that people using extraPrefs know to update thier cod.

Lastly, all the Prefs functions have renamed the "self" parameter to "super".  This is because "self" was never actually a self-reference in the object oriented sense
of the word.  For example

    Cabal_1_18_1_3 = self.Cabal_1_18_1_3.override { deepseq = self.deepseq_1_3_0_2; };

doesn't actually make sense from an object oriented standpoint because, barring further method overriding, the value of Cabal_1_18_1_3 would be trying to override it's
own value which simply causes a loop exception.  Thankfully all these uses of self were really uses of super:

    Cabal_1_18_1_3 = super.Cabal_1_18_1_3.override { deepseq = super.deepseq_1_3_0_2; };

In this notation the overriden Cabal_1_18_1_3 method calls the Cabal_1_18_1_3 of the super-class, which is a well-founded notion.

Below is an example use of using "extension" parameter

{
  packageOverrides = pkgs : {
    testHaskellPackages = pkgs.haskellPackages.override {
      extension = self : super : {
        transformers_0_4_1_0 = self.cabal.mkDerivation (pkgs: {
        pname = "transformers";
        version = "0.4.1.0";
        sha256 = "0jlnz86f87jndv4sifg1zpv5b2g2cxy1x2575x727az6vyaarwwg";
        meta = {
          description = "Concrete functor and monad transformers";
          license = pkgs.stdenv.lib.licenses.bsd3;
          platforms = pkgs.ghc.meta.platforms;
          maintainers = [ pkgs.stdenv.lib.maintainers.andres ];
        };
       });

      transformers = self.transformers_0_4_1_0;

      lensFamilyCore = super.lensFamilyCore.override { transformers = self.transformers_0_3_0_0; };
     };
   };
 };
}

Notice the use of self in the body of the override of the transformers method which references the newly defined transformers_0_4_1_0 method.

With the previous code, one would have to instead akwardly write

      transformers = super.finalReturn.transformers_0_4_1_0;

or use a rec clause, which would prevent futher overriding of transformers_0_4_1_0.
Allow for later binding in ghcPrefs

Now that both self and super are available to prefFun, we can use self, where appropriate to access late bound versions of most
packages.

When extensions are not used, there is no difference between self and super.
Update Node.js to 0.10.28
fetchFromGitHub: Use .tar.gz instead of .zip

Also clean up the name attribute of fetchzip derivations a bit.
When auto-formatting ext devices, use the -F flag to make it work with unpartioned disks
Merge pull request #2576 from NixOS/haskellPackagesFixpoint

Rework the knot-tying code for defining Haskell packages.
Merge pull request #2588 from c9/node-0-10-28

Update Node.js to 0.10.28
haskell-unix-memory: new expression
haskell-system-time-monotonic: new expression
haskell-generate: new expression
haskell-hcltest: new expression
haskell-quickcheck-property-monad: new expression
haskell-th-lift-instances: new expression
haskell-dynamic-cabal: new expression
Merge pull request #2592 from bennofs/haskell-new-expressions

Add a few haskell expressions
haskell-Strafunski-StrategyLib: jailbreak to fix build with GHC 7.8.2
conkeror: upgrade to latest snapshot
Re-write the Haskell Platform out of haskell-defaults.nix.

We used to configure library versions for every compiler that corresponded
(roughly) to the Haskell Platform that was current at the time the compiler was
released, i.e. GHC 6.10.4 builds would run with ancient versions of QuickCheck,
HTTP, etc. This whole approach is now gone. The Haskell Platform has no effect
on our default library selection any more; we generally provide the latest
version possible that the respective compiler can build.

To simplify our configuration even further, we dropped all intermediate GHC
releases from all-packages.nix. What remains is a haskellPackages_ghcXYZ set
for the latest version of every major release branch, i.e. GHC 6.10.4, 6.12.3,
7.0.4, 7.2.2, 7.4.2, 7.6.3, 7.8.2, and 7.9.x (HEAD snapshot).

Furthermore, there are some new features:

 - The ghcXYZPrefs settings in haskell-defaults.nix now automatically
   inherit entries from older platforms: an override configured in
   ghc722Prefs is automatically visible for all newer compilers, too. In
   the old scheme, entries that were necessary for multiple platforms
   had to be duplicated in all of them, so this change has reduced the
   number of necessary overrides quite a bit. The downside is that
   overriding an attribute for only one particular GHC version has
   become more difficult, because the override needs to be "undone" in
   the next "prefs" function to keep it from propagating. I've found
   that this is no problem in practice, because overrides that apply
   only to one particular GHC version don't occur much in practice.

   We could take things even further and split each prefs function into
   two: a ghc782OrLaterPrefs function, which does propagate its
   attributes, and a ghc782Prefs function, which does not. It seemed
   like overkill to do that now, though.

 - 'cabalLatest' is a variant of the 'cabal' builder designed that drives the
   build with a recent version of Cabal, instead of the version shipped with
   the compiler. This function is useful for building packages that use funky
   Cabal features that GHC 6.x and friends don't support. With this builder,
   the compiler will be able to handle those Cabal files.

   On modern compilers, however, cabalLatest does nothing, i.e. it's just an
   alias for 'cabal'. The reason for this is that overriding Cabal is tricky --
   it's a core library -- and a number of builds fail with version conflicts
   when built with a non-standard Cabal library. This applies particularly to
   every package that uses hspec/doctest for their test suite as these
   libraries depend on the GHC-API, which in turn depends on Cabal. So these
   packages always pull the native version in.

 - The 'cabal' builder has a brand-new argument called 'extension'. That
   function is "self : super : {}" by default, but, users can override it to
   mess with the attribute set passed to cabal.mkDerivation. An example use
   would be the definition of darcs in all-packages.nix:

   | darcs = haskellPackages.darcs.override {
   |   cabal = haskellPackages.cabal.override {
   |     extension = self : super : {
   |       isLibrary = false;
   |       configureFlags = "-f-library " + super.configureFlags or "";
   |     };
   |   };
   | };

   In this case, extension disables building the library part of the package to
   give us an executable-only version that has no dependencies on GHC or any
   other Haskell packages.

   The 'self' argument refers to the final version of the attribute set and
   'super' refers to the original attribute set.
haskell-gloss: update to version 1.8.2.1
haskell-wxcore: jailbreak to fix build with recent versions of array