Support for public sublibrary dependencies

[theobat]

At long last, I had the opportunity to look into this last evening and with all the prior refactoring things seemed clearer.
So, this brings several changes to stack :

• A refactoring separating ConstructPlan types to a dedicated module
• A change in the definition of the Installed type to add the support for installed sublibraries. This also brings several related changes such as : a change in DumpPackage, a change in LoadHelper and a change in the way we comptue package's flags for ghci
• Finally it also adds the correct lookups and dependency flags for builds of sublib dependent packages, which means it support sulib dependencies

This MR does not address many of the warts remaining because of the prior assumptions of stack (that is, for instance, we always build the main library, no matter what), but it's a good step in the right direction.

[mpilgrem]

@theobat, I've rebased on the master branch and added a commit which applies some reformatting for consistency. (It also adds the two new modules to exposed-modules in package.yaml.) I am going to do some local tests. Assuming they pass, I'll merge.

[mpilgrem]

@theobat, many, many thanks for cracking what I considered to be the No. 1 priorty for Stack. I'll give you proper credit when the next version of Stack is released (likely later this month).

[theobat]

That's really great @mpilgrem thanks for all the review and opnenness.
More is coming, I'm working on the actual component based build (instead of building all the components at once all the time which is current stack's behavior), one step at a time we'll reach backpack support in stack haha.

I'll describe a bit more in a dedicated issue.