Refactor Library Export process

[analogrelay]

Switch from ILibraryExportProviders to a single LibraryExporter class which understands a fixed set of Library types.

[analogrelay]

In this, we should also split the LibraryManager implementation class

[analogrelay]

/cc @davidfowl @lodejard

I'm going to do this in phases (but all still in beta7, though some phases could be bumped if necessary for time).

Phase 1

Split LibraryExporter out of LibraryManager (to match the interfaces), but keep it in the runtime. Also some small renames/renamespacing. Mostly just Microsoft.Dnx.Compilation.Caching -> Microsoft.Dnx.Compilation\Caching (i.e. rename the project, since non-caching things will be joining it)

Phase 2

Remove ILibraryExportProvider. Instead, we will have dependency providers create sub-classes of LibraryDescription (the internal type used to represent a library). Then, LibraryExporter will have a reference to the Runtime's LibraryManager (the concrete type) and use it to retrieve the strongly-typed LibraryDescriptions. The exporter will use the data in the LibraryDescription to export the library, using either virtual methods or down-casting. The loaders will also be factored to use this data, and thus the Project loader will move to Compilation. In theory, the project resolver could also move...

Phase 3

Move LibraryExporter and friends to Microsoft.Dnx.Compilation. This will mean Compilation will be coupled to Runtime, since it needs to use LibraryDescription and LibraryManager (which are in Runtime). However, this makes sense to me since Compilation is tightly coupled to Runtime. Whereas the Runtime is not tightly coupled to Compilation (i.e. the runtime could operate without the compilers). As part of this, we'll need to work out a way for ApplicationHost and DTH to stitch them back together, it might get a little ugly, but we can finesse it in Phase 4. Right now, I'm thinking that AppHostContext just gets a Func or interface that allows it to attach the compilation things (assembly loaders/exporters)

Phase 4

Final finesse and clean-up. The way we stitch Runtme and Compilation will probably be pretty ugly. Something like an ICompilationAttacherThingy in Runtime that Compilation implements. This will mainly be a refactoring of ApplicationHostContext, since that's where the stitching happens.

[analogrelay]

Phase 2-4 were completed by #2424 (despite the title only saying phase 2)