Allow specifying sbt.boot.properties as a URI

This allows straight forward system independent generation of the
property, since URIs are well specified and only support one file
separator.
Add pending test case for #958 (incremental compiler bug)

The ticket contains detailed description of the problem. The test case
just shows that if we set `incOptions := sbt.inc.IncOptions.Default`
then the incremental compiler doesn't recover from compiler errors
properly.
Recover from class files and Analysis object getting out of sync.

The #958 describes a scenario where partially successful results are
produced in form of class files written to disk. However, if compilation
fails down the road we do not record any new compilation results (products)
in Analysis object. This leads to Analysis object and disk contents to get
out of sync.

One way to solve this problem is to use transactional ClassfileManager that
commits changes to class files on disk only when entire incremental
compilation session is successful. Otherwise, new class files are rolled
back to previous state.

The other way to solve this problem is to record time stamps of class files
in Analysis object. This way, incremental compiler can detect that class
files and Analysis object got out of sync and recover from that by
recompiling corresponding sources.

This commit uses latter solution which enables simpler (non-transactional)
ClassfileManager to handle scenario from #958.

Fixes #958
Generate an error when the incremental compiler is given relative source files.  Fixes #923.

Review by @gkossakowski
Fix source-dependencies/relative-source-error to use explicit reloads.  Ref #923.
Replace binary Analysis format with a text-based one.
Reads/writes are a little faster with the text format,
and it's far more useful. E.g., it allows external manipulation
and inspection of the analysis.

We don't gzip the output. It does greatly shrink the files,
however it makes reads and writes 1.5x-2x slower, and we're
optimizing for speed over compactness.
Fixes #989, #990.  TrapExit jvm-independent and awt handling is only done when awt is used.

SecurityManager.checkAccess(ThreadGroup) is specified to be called for every Thread creation
and every ThreadGroup creation and is therefore jvm-independent.  This can be used to get all
Threads associated with an application with good enough accuracy.

An application will be marked as using AWT if it gets associated with the AWT event queue thread.
To avoid unwanted side effects of accidental AWT initialization, TrapExit only tries to dispose
frames when an application is so marked.  Only one AWT application is supported due to a lack of
a way to associate displayed windows with an application.
Resolved bugs reported in Issue 947. Also added SNAPSHOT suffix to the version by default.
Revised based on pull request feedback.