Summary:
This reverts commit aecf4a5f.

It turns out the Simons are relying on 'mk/are-validating.mk', see
D1307.

The workflow they are using is:
  * run ./validate
  * find a bug in the compiler
  * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
    of 'mk/are-validating.mk', this uses the same build settings as validate.
  * continue ./validate (--no-clean)

I suggested two alternatives:

  A. run 'make 1 Validating=YES' instead of 'make 1'

     Problem: when running `./validate --fast` or `./validate --hpc`
     instead of a normal `./validate`, validate sets ValidateSpeed and
     ValdateHpc in mk/are-validating.mk. You would for example have to run
     'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
     same build settings as `./validate --fast`, which is entirely too long and
     error prone.

  B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
     'mk/validate.mk'.

     Problems:
      * any other settings you have in build.mk will also get used.
      * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
        clear.
      * it is easy to forget to include 'mk/validate.mk'.
      * the build system again doesn't have access to the ValidateSpeed and
        ValdateHpc settings set by validate.

Neither of these two options is entirely satisfactory.

Reviewers: austin, bgamari

Differential Revision: https://phabricator.haskell.org/D1383