* default to commented line for nix config

* Fix whitespace

* Remove vscode folder

* Remove default config file for test

* Remove test generated file

* Add changelog

* Add test for default config values

* Remove config file

* Remove parsing file

* Add config file back for tests

* Remove reference to default config to try to get the new test to pass

* Rewrite test to be more verbose WIP

* Stop testing for values and only test for whether it is commented or not

* Fill out rest of tests WIP

* Clean up

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Restructures the `cabal init` command to fix historical
  issues. All flags are preserved.
  * Codebases for interactive and non-interactive flags
    are disentangled.
  * Data structures now exploit relevant stanza structure
    and formatters only care about stanza data
  * Heuristics and prompts have a pure and impure implementation.

* Sets default behavior to be `--interactive` as opposed to
  `--non-interactive`.

* Rewrites tests to achieve 98% coverage
  * Golden files now test every stanza individually
  * Every flag is covered by a unit test
  * Interactive, simple, and non-interactive workflows are
    covered.

The key item captured in this test is that when 'cabal init --libandexe' is run
in an empty directory it will result in a dependency on the library from the
executable in the form of 'build-depends = <package-name>' but with no version
constraints since they are implied by the version of the current package.

This matches what is produced by PrettyField, so that when we switch over the
cabal file generation from manual formatting to PrettyField formatting we see
the true diffs and less field indent line noise.

At the top level we now have cabal/ and cabal-install/

This patch adds intrapackage dependency resolution so that components
(libraries, exes, test suites) are build in the correct order.  This mean it's
now possible to have, e.g., executables that depend on other executables defined
in the same package description: the build-tools namespace has been extended
accordingly.
  
Related to this change is the refactoring of the do-it-all preprocessSources
function, formerly invoked by initialBuildSteps, into a a function
preprocessComponent that is invoked when a component is being built.  This lets
us use executables defined in a package to be used as a custom preprocessor when
building other components.
  
Finally, a number of functions now operate on values of the sum type
PackageDescription.Component rather than specifically operating on Library or
Executable and so forth.

This patch adds the 'testEnabled' field to TestSuite. It's 
undesirable to track build status information in the static package 
description, but there is no better solution at this time. This 
patch has the side-effect of fixing several TODOs in 
Distribution.Simple.Configure.

Should live in the ghc testsuite but no harm having it here too.

Still some other tests that need hooking up to this mechanism

Ticket #215 (Overhaul support for packages' tests).  The update to the
TestSuite parser which stopped disallowed configurations during parsing also
broke the existing test suite with API changes.

Ticket #215 (Overhaul support for packages' tests).

Ticket #215 (Overhaul support for packages' tests). Parse and
finalize a simple, dummy .cabal file containing a Test stanza.
Compare with the PackageDescription it which should result
from parsing.

The problem was that we do the QA check on using the new version range
syntax after parsing. The new syntax allows ()'s but previously the
code threw them away in the parser stage. We now retain them in the
AST and deal with them appropriately. This now allows the QA check to
be accurate and detect things like "build-depends: base (>= 4.2)".

Fixes ticket #693.

In case we've got a compiled Setup binary

rolling back:

Mon Oct  5 17:32:02 BST 2009  Stephen Blackheath <grossly.sensitive.stephen@blacksapphire.com>
  * Fix test case InternalLibrary4 on account of a change in Cabal's behaviour.

    M ./tests/PackageTests/BuildDeps/InternalLibrary4/Check.hs -5 +4

They all get squashed to ">1 && <1" which while canonical is not helpful.

Now foldVersionRange gives a view with no syntactic sugar
while foldVersionRange' gives a view with the syntactic sugar.

The purpose of these tests is mostly to pin down some existing behaviour to
ensure it doesn't get broken by the ticket #89 changes.

One property fails. The failure reveals that the VersionInterval type
is not quite a canonical representation of the VersionRange semantics.
This is because the lowest Version is [0] and not -infinity, so for
example the intervals (.., 0] and [0,0] are equivalent.

For Functor, Monoid and Traversable.