Fix an instance where we swapped -source and -target.

Summary:
I guess folks always set these to the same value since this bug
has been around since May 2013.

Test Plan:
Changed the value to `source = 7` on an `android_library()` and built with `-v 2`
and verified that `-source 7` was passed to `javac`.
Modify genrule()'s srcs to be SourcePaths instead of Paths.

Summary:
Any `srcs` that are `BuildRuleSourcePath`s are added as extra deps
to the `Genrule`'s `BuildRuleParams`. This means that instead of:

```
genrule(
  name = 'example',
  srcs = [ genfile('foo.jar'), genfile('bar.jar') ],
  cmd = 'some_command $SRCS',
  deps = [
    ':bar',
    ':foo',
  ],
)
```

You can now do:

```
genrule(
  name = 'example',
  srcs = [ ':foo', ':bar' ],
  cmd = 'some_command $SRCS',
)
```

Hopefully this is the last diff needed before `genfile()` can be removed.

Test Plan: Sandcastle builds.
Ensure values_file is built before android_build_config().

Summary:
Fixed this bug by adding `values_file` to the `extraDeps` of the
`BuildRuleParams`. I think this is an example of a bigger issue that
@simons is looking at where `SourcePath`s are not automatically
added as `extraDeps` to a `BuildRuleParams`.

Note that this also fixes the issue for `build_config_values_file` in
`android_binary()` because `AndroidBinaryGraphEnhancer` delegates
to `AndroidBuildConfigDescription.createBuildRule()`.

Test Plan:
Built an `android_binary()` that had a transitive dependency on an
`android_build_config()` with a `values_file` argument. Verified that
the APK did not built without this change, but built with it.
Deprecate genfile() and eradicate it from the codebase.

Summary:
Notice must be sent out to the discussion group that this function
is being removed so that developers can update their BUCK files accordingly.

Test Plan: Sandcastle builds.
Change ios_library to always output to its fully qualified identifier.

Summary:
Currently the generated Xcode project will output all build products to a
shared directory, which is its default behaviour. Buck however does not normally do
this, and does not enforce uniqueness of short name, just of fully qualified
identifiers. This can cause build rules to overwrite each other's output files.
This changes ios_library to always output to a unique directory by resolving its
fully qualified identifier.

Test Plan: Includes unit tests.
Remove emma support in favour of jacoco.

Summary:
emma is a little long in the tooth, and jacoco is kept up to date. Rip out emma
and just leave jacoco behind.

Test Plan:
buck test --all
buck clean
buck test --all --code-coverage
Extract both target GIDs and target names in ProjectParser.

Summary:
To generate Xcode schemes that xctool can read, we need
four things for each target:

1) The target's GID ("BlueprintIdentifier")
2) The target's Xcode project ("ReferencedContainer")
3) The target's name ("BlueprintName")
4) The result of building the target ("BuildableName")

We were previously missing 3) and 4), but in D1439254, I added them by
reading the PBXFileReference for each target.

This worked well for everything except xcode_native targets, which use
a fake target (see
WorkspaceAndProjectGenerator.generateWorkspaceAndDependentProjects()).
This fake target doesn't have a PBXFileReference,
so my logic in D1439254 crashes with an NPE.

We can get the data we need for xcode_native targets by building on
the existing ProjectParser call added in D1311030 to extract not
just the (target -> GID) maps, but also the (target -> filename)
maps for the BuildableName in the scheme.

This adds a new API
ProjectParser.extractTargetNameToGIDAndFileNameMaps() building on the
old API ProjectParser.extractTargetNameToGIDMap(), along with tests.

Test Plan:
Unit tests included.
Tidy up out-of-date comment in XcodeNative.

Summary:
Jason removed these parameters in D1311029 but we
forgot to update the docblock.

Test Plan: None.
Ensure generated schemes correctly handle xcode_native targets.

Summary:
This is a follow-up to use the new ProjectParser API added
in D1459445 to fix the NPE Buck throws when generating schemes that
include xcode_native targets.

Test Plan:
Ran buck project --workspace-and-projects in fbobjc.
Before, NPE. Now, it correctly generates the workspaces.

There are no tests yet for WorkspaceAndProjectGenerator;
I filed a task to address this.
Initial thrift support.
Make watchman optional again.

Test Plan:
Set up autobuild
buck build buck
buck clean
verify hook is still there
Lazily construct TargetNodes in the Parser.

Summary:
We currently create every TargetNode in every build file we read, which means that
the parser is (potentially) coercing too many rules. In the common case, this will
be a no-op change (since most build files only have one rule in them in any case),
but in complex cases, we should be a little more efficient.

This also sets the stage for being able to address a flavoured target directly,
since this change mediates all access to TargetNode instances through a single
method accessed while building the Target Graph.

Test Plan: buck test --all
Fix lint warnings in ReportGenerator. No logical changes.

Summary:
Working on the report generator for code coverage is problematic since it contains a number
of lint warnings. Fix those lint warnings.

Test Plan: ant lint && arc lint
Leverage SourcePaths.filterBuildRuleInputs() in AndroidManifestDescription.

Test Plan: Sandcastle builds.
Include comment in generated BuildConfig.java that it is a generated file.

Summary:
The comment also includes the [unflavored] BuildTarget that was responsible
for generating the file.

This diff also introduces `BuildTarget.getUnflavoredTarget()`.

Test Plan:
Updated appropriate unit tests.
Sandcastle
Allow specifying GID in iOS target settings.

Summary:
Currently, there are two ways to set the Xcode "global ID" (aka "gid")
for a target:

1) Automatically generated using a stable hash algorithm
2) From an existing project file on disk

together.

in to source control.

During a transition, some repositories will be in a blended state where
they check in non-generated workspaces and schemes which refer to generated
projects. Those schemes will contain GIDs referring to projects on disk.

To make the transition easier, we'll allow a new method to set the Xcode GID
for a target:

3) Specified in the "gid" parameter in the BUCK file

This will allow us to generate the projects with a specific GID so the
existing schemes can continue to work.

Test Plan: Unit tests updated.
Ensure project generation reserves GIDs specified in BUCK files.

Summary:
Thanks to @coneko for pointing this out. In D1461424, I
added the ability for generated projects to specify their GIDs.

However, I forgot that we need to generate GIDs for other targets,
which theoretically could conflict with these hard-coded GIDs.

This adds a test and fixes the bug.

Test Plan:
Wrote unit test, confirmed it failed. Applied patch, test passes.
Allow java code coverage to be collected in a variety of formats.

Summary:
Jacoco (and most coverage tools) allow coverage reports to be generated in a number of
formats. Expose that functionality.

Test Plan:
  buck test --all --code-coverage --code-coverage-format html --no-results-cache
  buck test --all --code-coverage --code-coverage-format xml --no-results-cache
  buck test --all --code-coverage --code-coverage-format csv --no-results-cache
Eyeball generated files:
  less buck-out/gen/jacoco/code-coverage/*