Add @Nullable annotations to ExecutionContext.java

Summary: Add @Nullable annotations to ExecutionContext.java

Test Plan: buck test --all
Null check in TestResultsGrouper.java

Summary: checking for a null that can lead to a potential NPE

Test Plan: The code does strictly less, apart from throwing an NPE earlier
Delete unused DescribedRule class.

Summary: There's a TODO to remove this class. It's good to do a TODO sometimes.

Test Plan:
buck test --all
Feeling of delight as KLOC of Buck decreases a little.
Fixing some @Nullable inconsistencies in java/, model/ and parser/

Summary: Fixing some `@Nullable` inconsistencies and documenting some implicit assumptions using `Preconditions.checkNotNull`

Test Plan: buck test --all
Fixing some @Nullable inconsistencies in shell/

Summary: Fixing some @Nullable inconsistencies and documenting some implicit assumptions using Preconditions.checkNotNull

Test Plan: buck test --all
Split BuildRuleResolver#get into two methods.

Summary:
BuildRuleResolver#get currently accepts a @Nullable parameter and
returns a @Nullable value, forcing callers to check for null as a
precondition. This splits the method into two versions: one that
guarantees the return value is not null and fails if the rule
cannot be resolved, and one that returns an absent optional if the
rule cannot be resolved.

Test Plan: CI
Add BuildRuleResolver#getAllRules.

Summary:
Since we'll be using BuildTarget in ConstructorArg to be able to use
them in TargetGraph while still delaying the creation of BuildRule,
we'll need to often resolve ImmutableSortedSet of BuildTarget. This
adds a method to BuildRuleResolver to do that.

Test Plan: CI
Add @Nullable annotations to rules/.

Summary: Add @Nullable annotations to rules/.

Test Plan: buck test --all
Change ConstructorArg implementations to only reference BuildTarget.

Summary:
ConstructorArg currently reference BuildRule. That means that coercion requires
tranforming the TargetGraph into an ActionGraph. Changing ConstructorArg to
reference BuildTarget instead allows us to coerce in the TargetGraph before the
transformation to ActionGraph.

Test Plan: CI
Add @Nullable annotations to buck/android.

Summary: Add @Nullable annotations to buck/android.

Test Plan: buck test --all
Annotated files with @Nullable in log/ and util/.

Summary: Annotated files with @Nullable in log/ and util/.

Test Plan: buck test --all
Mark return values from ProjectFileSystem as Immutable

Summary:
They're immutable (or treated as immutable) in any case. Better call this out
in method signatures so that null-checking is simpler.

Test Plan: buck test --all
Consolidate common constructor args across C++ descriptions

Summary:
Most of the C++ description typs share the same core set of fields,
so move these to a base class and have them all inherit from that.

Test Plan: buck test --all
Parser: unify recursive and explicit target graph parsing

Summary:
Currently, we support two ways of parsing and constructing the
target graph:
1) Parse starting from a list of explicit targets.
2) Recursively search for all build targets in the repo.
The former was mostly done in java, with the buck.py python parser
handling parsing individual build files.  The latter delegated to
the buck.py python parser to perform the recursive search of all
build files and then parse them and return them as one blob.

This diff unifies the target graph parsing around a single method
in the parser, which uses new target node specification objects to
describe the various parsing styles we support, which is currently
just a recursive search based on ##RuleJsonPredicate## and an exact
match base on explicitly specified ##BuildTarget## objects.  In both
cases, the major lifting is all done in the parser, including
recursive parsing, which showed to be a lot faster than it's python
equivalent (this made "buck targets" twice as fast in fbcode).

This also opens the door to introduce new specifications to control
how the target graph is built.  In particular, it's be interesting
to support some UI to build or list targets for all packaging rules
under a particular directory (which would be really useful for
automation).

Test Plan: buck test --all