Large re-organization to remove cyclic module dependency graph

Related to #187. The current `master` module hierarchy evolved organically with much sharing between files, making it a mess of a graph (see @hvr's picture).  This pull request finally corrects that. Opening as a pull request because any changes you guys have committed locally will have to be rebased. So I suggest you push your changes first and I will rebase upon them. However, the longer this goes unmerged it will be harder to do so. I'm going to give it a grace period of a week before merging, although if everyone is happy to go ahead I'll merge it sooner.

I wrote a trivial script that would rm all `.elc` files and byte-compile just the file I wanted to test. Using that, I ran it on every file in the project to see that every file had the proper `require` dependencies. Naturally, the HIM modules were all an interloping mess, so I've significantly moved code around so that the hierachy fits. Here is the new hierarchy:

![deps](https://cloud.githubusercontent.com/assets/11019/5235140/a561a0a6-77ef-11e4-9e9d-f62afc293725.png)

As you can see, at the top is the `haskell` module. Given that the `haskell-mode.el` module contains the mode, it didn't make sense to have everything being pulled into there, especially given that many things depend on `haskell-mode.el` itself. So we end up with three 'big' modules that are depended on a lot: `haskell-mode.el`, `haskell-interactive-mode.el` and `haskell-process.el`. I removed all the specialized commands and things from haskell-session, haskell-process and haskell-interactive-mode into haskell-load or haskell-commands. It makes those modules nice and small (relatively speaking). I would like to do further breaking down of that `haskell.el` file until it's nearly just a list of imports. 

I didn't actually rename any functions, though I would've liked to (using `make-obsolete`), but that would be far more problematic. The point is to move things in the right files. It's not entirely finished, nor am I sold on the particular module naming, but I consider this a big step in the right direction. After this we can incrementally improve.