Treat flags with much less priority.

This implements two changes:

(1) Flag choices are deferred whenever possible.
(2) If a package appears on both branches of a conditional, the
    unconstrained package is lifted out of the conditional.

In combination, we're trying to achieve that the solver should pick
a package before the flag, and thereby e.g. respect installed package
versions.

This is adequate in the common use case that flags are simply
representing a disjunction, and should be rather weak.

We'll have to see what happens in the few other situations where flags
are really representing optional features. I'd expect, however, that
in such situations there are targets in one branch, and not the other.
Then the flag choice would still happen prior to the corresponding
target.
Configurable strong/weak flags.

This adds a mechanism in the modular solver to store whether a flag
is "strong" or "weak". A weak flag is deferred during solving, a strong
flag is not.

By default, flags are now weak unless they're manual. This is a change
in behaviour, but I think it's probably the better default, because many
automatic flags are used to figure out what's on the system rather than
to impose hard constraints.

There's a new flag --strong-flags that restores the old behaviour. I do
not think such a global flag is particularly useful, but it may be
of interest to compare build plans between the new and old behaviour.

With these preparations, it's easy to make the distinction between
strong and weak flags more sophisticated. We can either add more
heuristics as to when flags should be treated as strong or weak, or we
can add syntax to .cabal files that allows package authors to specify
explicitly how they intend a flag to behave.

This is related to various cabal-install issues, e.g. #1831, #1864,
and #1877.
Merge branch 'defer-flags' of https://github.com/kosmikus/cabal

Conflicts:
	cabal-install/Distribution/Client/Freeze.hs