Clean up the library testing story

[simonmar]

Our story for testing libraries is in disarray, and needs cleaning up. Tests for libraries can now be placed in the repositories with the libraries themselves, and these tests are picked up when you say make in testsuite/tests/ghc-regress.

The following tests need to be moved into their respective packages, and in some cases given appropriate .T scripts:

• everything in testsuite/tests/libraries
• everything in testsuite/tests/ghc-regress/lib

tests that are package-specific but are really GHC regression tests should stay in the testsuite, and use the reqlib option.

[duncan]

In my opinion, we should try to have libraries use the new cabal test interface (improving that if necessary) and the ghc testsuite can call that.

We want the cabal test interface anyway since it gives a standard interface for all packages and will let us share continuous testing infrastructure across all packages (e.g. the HP).

[simonmar]

How would cabal test interact with the GHC testsuite infrastructure? We have lots of parameters to pass in (compiler, flags, ways etc.), and information to get out again (the result of each test), and some infrastructure we might want to share (the test driver).

I'm wondering whether a better approach might be to have both an all.T as well as the cabal test infrastructure (whatever that might be) for each package.

[igloo]

lib/Data.ByteString tests sent to bytestring bug report addresses. I'll remove them from testsuite once we've stopped merging everything to 7.4.

[igloo]

Can't finish this in 7.4, as we aren't pulling library patches from upstreams any more, so punting.

[pcapriotti]

All tests have been moved to the appropriate repositories.

The only thing remaining in lib/ is integer, which should probably stay there, since it is not specific to the Integer implementation, so I'm closing this.