Sbt: clean up source code

[tpolecat]

So, at least for me the state of the source code is a big barrier to contributing. It's poorly formatted, sparsely commented, and in places it's organized strangely. So I suggest a cleanup task to be done at some point post-1.0 when we're free to make "big" changes. In this case the changes are trivial but global and will result in a huge PR. Anyway:

• Run everything through scalafmt to make formatting consistent and introduce some whitespace between definitions.
• Add Scaladoc comments explaining at least what every class does. Ideally every public member would be documented but that's too much to ask initially.
• In some places there are a bunch of definitions in the same source file that might work better split up into multiple source files.

After this is done I think it will be easier for me (and hopefully others) to get some momentum in trying to understand how the hell sbt actually works so we can start making meaningful improvements.

[eed3si9n]

I agree that sbt's code base is very difficult to tackle.

Not sure what goes to pre- and post-1.0, but my approach to solving this is to split sbt into distinct modules and clarify public API vs internal implementation (rather than trying to make everyone understand every class). I'd say nearly half of sbt 0.13 code is around incremental compilation and supporting classes. But for most contributors, incremental compiler can be a simple function that takes your source files and generates *.class files, and don't have know about the details.

Similarly, library management is thin wrapper around Ivy, and something people can totally get into and improve, but we should also be able to abstract it out as a simple function that takes sequence of ModuleIDs and generates Files.