Use interfaces in preference to concrete types when calculating classpaths.

Summary:
Coding to interfaces is preferable to coding to concrete types. This loosens the
contraints of `JavaLibraryClasspathProvider` so that anything that implements
`JavaLibrary` can have its classpath calculated.

Test Plan: buck build buck
Introduce a TargetGraph class so that BuildEngines can make use of it.

Summary:
There are commands, such as when auditing owners, that only need access
to the TargetGraph and not the ActionGraph. Expose this as a type that
can be accessed from the Parser.

A later diff will move construction of the ActionGraph out of Parser
and (probably) into this class.

Test Plan: buck test --all
Simplify logic to filter deps of type JavaLibrary.

Test Plan: sandcastle
Handle build info parse errors gracefully.

Summary:
Currently parse errors encountered while reading metadata
from disk cause exceptions to be thrown which fail builds. This change
allows parse errors to be treated in the same way as missing metadata
files: steps are rerun to regenerate the missing or invalid
files. This allows builds to be more resilient, gracefully degrading
rather than failing in the face of invalid metadata.

Test Plan: buck test --all
Use enum instead of string now that we have EnumTypeCoercer.

Test Plan:
buck test --all
sandcastle
Update regex to parse buck logs in the perf test.

Summary:
4a2509af2f0b0107c52763e28e1a00e26527ce39 changed the format of log messages,
but did not update this regex.

Test Plan: Manaully test the regex in python interpreter on a bunch of log lines.
Include android resource's package name in its ABI key.

Test Plan: Integration test (which fails without this change).
Remove consoles from daemon objects.

Summary:
Once the Daemon can be used by multiple commands concurrently
it will no longer be able to rely on always being able to use a single
Console as every method call may come from a different, concurrently
executing, client. This change anticipates concurrent multiple
commands by removing the Console fields from the Daemon, web server,
Parser and FileHashCache. Where possible the previous uses of the
Console are replaced by calls to Loggers. Where this is not possible the
Console is passed to each method call.

Test Plan: buck test --all
Generate per package uber R.java with minimal set of ids.

Summary:
Earlier, we invoked `aapt` on all the transitive android resource deps of an
android binary to create an R.java per package, each containing symbols from
all the packages. As a result, if you have N total symbols from k different
packages, you'd have k R.java files each with N symbols. This is not an issue
for release builds where proguard strips out unused fields, but debug builds
would hit the 65k limit on the primary dex easily.

This diff:
- merges R.txt of *all* transitive android resource deps into a set of resources per package.
- generates the uber R.txt with real IDs by invoking `aapt` as before, but ignoring the generated R.java file.
- Iterates over entries in resources per package, finds the resource in the uber R.txt, and replaces its ID with the real ID.
- Writes the resulting resources to the corresponding R.java files.

Test Plan:
Updated/moved unit tests.
Make generating R.txt return a list of steps instead of a composite step.

Summary:
It just looks better on the console. Also, easier to track time taken by `aapt`
step overall.

Test Plan:
buck test --all
buck build instagram
Pass environment to daemon methods.

Summary:
Once the daemon can be used by multiple commands concurrently
it will no longer be able to rely on always being able to use a single
environment as every method call may come from a different, concurrently
executing, client. This change anticipates concurrent multiple
commands by removing the environment from the Parser. If the Parser
is asked to parse a build file with an environment that differs from
the one used to populate the cache, the cache is invalidated and the
build files reevaluated. This mimics the behaviour used to invalidate
the Parser cache when the default include files are changed.

Test Plan: buck test --all
Remove dead code.

Test Plan: sandcastle
Allow Descriptions to declare which Flavors they support.

Summary:
As we build the target graph, it's useful to know whether the targets being referred to
can actually be built. Currently, the only flavour that can be addressed directly is the
default one. As we expose Flavors directly, however, this will not be the case.

Test Plan: buck test --all
Change default http cache port to 8080.

Summary: s/5551/8080/

Test Plan: buck tests still pass
Create the RepositoryFactory.

Summary:
In order to support cross repo targets properly, we need a Repository to be
able to reference other Repositories, with in turn reference others, and so on.
We don't want to create all these up front, both because we want to avoid the
IO, and because we don't want to throw errors on missing repositories unless
the user actually needs them. So we need to abstract away repo creation into
a class that I'm calling `RepositoryFactory`, because Java has poisoned me.

Test Plan:
Unit tests still pass. Many of them now rely on the new
`TestRepositoryBuilder`.
Add a flavour to java_library and its ilk that provides a source jar.

Summary:
Not yet exposed to people, but this will be used to ensure that we can address
flavours on the command line and within the target graph (and get the right
thing pop out the end in the action graph)

Test Plan:
buck test --all --code-coverage
Make sure the tests pass
Make sure that the coverage looks ok too.
Allow BuildTargetParser to canonicalize repo names.

Summary:
The biggest problem that comes up with cross-repo targets is disambiguating
targets across different repos. Two projects could each have a target with
exactly the same name. Also, two projects could use the same repo name to refer
to two different external repos. And of course, we don't use any @repo name at
all when referring to targets within the current project.

The solution in this RFC is to pick a canonical name for every repo touched by
a build, and to translate build targets into the canonical form when they're
parsed. (This is similar to how we translate short targets like `:foo` into a
full target at parse time.) This means that all references to `//bar:baz` in
the external repo "foo" will actually get parsed into the build target
`@foo//bar:baz`. The root repo (where buck is run) will have an empty canonical
name, so most of buck's current output and error messages won't change.

The only alternative to doing this that I can think of, would be to attach some
other form of context to the build target itself, which rapidly devolves into
having the build target carry its own `ProjectFilesystem` and other nastiness.
An upside of the "canonical repo names" approach is that build errors that
happen in an external target should make more sense to the user.

Plumbing this change all the way through will require substantial changes to
the `Parser` class that aren't ready yet. There are many places where it
assumes a global `ProjectFilesystem` or `ProjectBuildFileParser` that need to
get with the times. I've thrown in some comments to hint at these changes.

Test Plan:
Updated `BuildTargetParser` unit test. Countless future integration
tests when cross-repo targets are actually working.
Use Jacoco to create a code coverage report; update build scripts to run it.

Summary:
We used to measure code coverage with EMMA, but it proved to be too flaky to
run on every build. This diff introduces a script to measure it with Jacoco:

```
buck test --all --code-coverage --code-coverage-format xml --no-results-cache
python scripts/assert_code_coverage.py
```

The script prints out a summary of code coverage by package to the console.
It returns with a non-zero exit code if code coverage by line drops below 78%.
Currently, we are at 81.06%, so hopefully we can maintain this (or even better,
crank it up over time).