In Cabal 1.22.5.0, the semantics of
--disable-profiling/--enable-profiling depend on ordering (because there
is a hack that operates by looking at the current flag assignment and
doing something). In particular, if I specify --enable-library-profiling
--disable-profiling, I end up with library profiling DISABLED.

The fix is that we NEVER pass --enable-profiling or --disable-profiling
to Cabal. At the moment, and according to my historical analysis, Cabal
ONLY uses configProf to affect the effective library/executable
profiling, which means that anything we do with --enable-profiling, we
can do using the library/executable profiling individually. Since these
are always flags for the versions of Cabal library we support, we will
get order invariance. Historical versions have varied on whether or not
setting executable profiling implies library profiling, but if we set
both explicitly this change in behavior doesn't matter.

This patch is difficult to test because the bad profiling flags
can't be induced on an inplace build.  I tested by hand by building
a package that depended on 'distributive' by hand.

Fixes #3790.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>