And inline the actual used function in the companion of
`IncrementalCommon`, with a better and simpler implementation.

While I was trying to implement some improvements here, I realize that
the current code can hardly be read and reused. I struggled as well to
understand the nitty-gritty of the algorithm as the control flow was not
clear and the order of functions was confusing.

This commit aims to fix this by reorganising the code to allow for more
reuse (functions in `IncrementalCommon`'s companion), reorganizes the
outline of `IncrementalCommon` to have clearer names and structure and
documents the most important parts of the code with implementation and
contract details.

zprof is the name I've chosen for this small profiler (or tracker if you
will) of the invalidation logic. The profiled data is formalized in an
internal format that is not supposed to be used by normal users, but
rather by us (Zinc) and related tools (Bloop).

The current profiled data exposes details of how the incremental
compiler works internally and how it invalidates classes. This is the
realization of an idea I registered here: sbt#550

With this idea, this data will not only be useful for debugging but for
providing an automatic way of reporting bugs in Zinc. The infrastructure
is far from finished but it's already in a usable state for libraries
that depend on Zinc directly and have direct access to `Incremental`.

By default, no profiler is used. Only people that change the profiler
argument for `Incremental.compile` will be able to get the run profiles.

These methods are not exposed to the public API of Zinc and can
therefore be changed with certainty.

I realized how stupid it was the idea of keeping two string tables
intead of one, since it's unlikely we'll ever have more than
2147483647 unique string instances and the JVM doesn't allow to
instantiate such a big array in normal heap sizes. So we remove this
part of the design that we inherited from pprof.