Work on dbuild 0.9.0, stage 2/5

[cunei]

This is the first part of the refactoring needed to implement the sbt plugins support. The code is completed by the subsequent chunk of commits, which will follow in a separate pull request. In this pull request, many settings and internal structures are transformed into Seq[], so that each applies to subsequent "levels" of an sbt build, where the base level is the regular project definition, the subsequent level represents the definition of the project plugins, then plugins of the definition of project plugins, and so on. The Seq[] that refer to levels are all marked using the /Levels/ comment in the code, for clarity. The dependency extraction (DependencyExtractor for sbt) is then tuned so that information about the dependencies of each level is captured; that is done using a set of "onLoad" definitions, invoked via files that are dropped into the proper place into each level in the source tree. Next, the rewiring stage is reimplemented in order to conform to the new code structure: BuildArtifactsIn is transformed into a BuildArtifactsInMulti, representing incoming artifacts for all the needed levels of a build. Rematerialization is adapted accordingly. The use of properties to communicate data from the sbt runner to the dbuild plugin is largely dropped, in favor of files that are in known locations, relative to the project base build directory: the exact locations are all defined in SbtRunner.SbtFileNames (for sbt builds), and BuildDirs (for all builds). For sbt, SbtBuildRunner is updated so that rewiring works as intended on all levels: the files which add "onLoad" are placed at the appropriate locations throughout the project source tree, and just calling sbt will cause those onLoad handler to be executed, and therefore the rewiring to take place. Again, please note that this is only half of the sbt plugins support, chopped in half for reviewing convenience; the subsequent pull request will complete this code with the actual building and additional fixes to this code.

[jsuereth]

Generally the code comments, look great as always. One comment on the direction of the metadata design, which we may have to circle back to later.

Otherwise LGTM (caveat the minor comments).

[cunei]

OK! Under the provision that the current rematerialization logic is an intermediate solution, pending adding locking, I will merge this PR and submit the following one.