Goofy build product destination for generated C files

Steps to reproduce:
1. Build `Cabal:package-tests` and run `PreProcessExtraSources`
2. Look at the recursive contents of `Cabal/tests/PackageTests/PreProcessExtraSources/dist-test`

Expected result: it should make sense.

Actual result: we find that there is a doubly nested directory hierarchy `dist-test/dist/build/dist-test/dist/build`.

Here's the problem.

Ordinarily, when a Cabal project has a C source file, it is somewhere in the top-level directory of the Cabal project. When we invoke GHC to compile it, we pass GHC `-odir dist/build` to make sure the resulting object file gets placed in the correct place. Now, what are the semantics of `-odir`? Clearly if I say `ghc -c foo.c`, I want the object file in `$odir/foo.o`. But what if I say `ghc -c a/foo.c`? In analogy to the way Haskell compiles Haskell files, I might reasonable want the result to go in `$odir/a/foo.o`.

Some C source files are automatically generated, however (e.g., because we ran `hsc2hs`). In that case, the source file is placed not in the top level directory, but in `dist/build`. Then, when we compile these, we pass GHC `ghc -c dist/build/Foo_hsc.c -odir dist/build`. In this situation, GHC (rightly) places the resulting object file in `dist/build/dist/build/Foo_hsc.o`. Dastardly.

I think this is relatively harmless, however. Specifically, we do a full recursive scan of the `dist/build` directory to pick up these source files, so it doesn't really matter where we put them. It is a bit unsatisfactory though. One possible fix is, IF the source file is already in `dist/build`, then suppress `$odir`. But that's yet another special case. It's also somewhat desirable for autogenerated files to be put in a different `$odir`...