Doc tests using doctests-driver-gen

[andreasabel]

This contributes:

• a few doctests, testing
  • Plain http(s)-links in markdown not rendered #1000
  • Email address detection in markdown faulty #1001
• a new test-suite DocTests running these tests

This required me to:

1. depend on doctest and doctest-driver-gen
2. move the library code into src:
   I cannot pass . (where currently the library sits) to doctest, as this would pick up also the exes, and they all define module Main, which of course gives ambiguous module names and is not liked by ghci.
3. add write-ghc-environment-files: always to cabal.project.

Step 2. is maybe a big change, but it is in a single commit, so rebasing PRs should work (I rebased a bit back and forth over this commit locally, and it went fine). Putting the library in a subdir is the standard practice, so in the long run we have to do it at some point.

How to run the doctests:

cabal build --enable-tests DocTests
cabal test --enable-tests DocTests --test-show-details=direct

The first step writes the .ghc.environment file which is needed by cabal test.
One could skip writing the environment file, but then it would need to be prefixed by cabal exec:

cabal exec -- cabal test --enable-tests DocTests --test-show-details=direct

As usual, running doctest is very slow (30 sec on my mac). I also tried doctest-parallel in #1014 (https://github.com/haskell/hackage-server/blob/parallel-doctest/tests/DocTestMain.hs), but I didn't get it to work, and also it did not appear too much faster (17 sec getting to the point where it failed).

[gbaz]

I think moving the library into a subdir is worth it on its own. This historical quirk of the hackage codebase (reflecting its age) has always been a bit irritating.

[andreasabel]

I think moving the library into a subdir is worth it on its own. This historical quirk of the hackage codebase (reflecting its age) has always been a bit irritating.

Ok, I am pushing this part then.

[andreasabel]

Closing in favor of #1014.