Make compatible with `network-2.4` API

The specific API change in `relativeTo` this changeset
compensates for has been introduced in

 haskell/network@4a3fdefe2228e0998bbf80969e5dddf943ebe99a
Merge pull request #1044 from hvr/network24

Make compatible with `network-2.4` API
Merge branch 'cabal-1.16'
Use standard function launch process in test code
Fall back to looking on the path for ghc-related tools

This fixes things for situations such as where hsc2hs is in /usr/bin
but ghc is in /usr/local/bin, where previously we'd get:
  cabal: The program hsc2hs is required but it could not be found
Make test failure reason more clear in output
More test output tweaks
Fix test output of even more tests
Give more info when unregister fails in a test
Add a policy for which versions of GHC Cabal supports being built by
Supported GHC policy means that we always have base >= 4
Remove some CPPery for old, no-longer-supported versions of GHC
Merge branch 'master' of github.com:haskell/cabal
Use the time package rather than old-time
On install, update the .cabal file with the one from the index

This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.
Extend the unpack command for the .cabal file updating

By default, "cabal unpack blah" will also update the .cabal file with
the one from the index, so it's consistent with what you get via
cabal install. Also added a --pristine flag so you can get the original
tarball without the updated .cabal file.
On install, update the .cabal file with the one from the index

(patch manually merged into the cabal-1.16 branch)

This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.
Extend the unpack command for the .cabal file updating

By default, "cabal unpack blah" will also update the .cabal file with
the one from the index, so it's consistent with what you get via
cabal install. Also added a --pristine flag so you can get the original
tarball without the updated .cabal file.
Bump Cabal version number to 1.16.0.1
Bump cabal-install version number to 1.16.0