Don't bother finding the repository root for trivial cases

Summary:
When running `buck --version` (or `buck -V`) we don't need to navigate up to the repository root.

This is a pretty hacky fix.  There is probably a much nicer way of doing this, that generalizes and pays off some debt!

Test Plan: Run it on the command line.
Stifle rejection exceptions from ThreadPoolExecutor

Summary:
Before submitting D1051066, @jimp added a multi-thread
version of MoreExecutors.newSingleThreadExecutor(),
MoreExecutors.newMultiThreadExecutor.

Unfortunately, unlike newSingleThreadExecutor(), this multi-thread
version didn't stifle the exceptions raised by the default
ThreadPoolExecutor when submitting tasks after the executor is
shutdown.

This diff makes both executors stifle exceptions when rejecting
tasks after shutdown, which gets rid of this log error when
builds fail:

https://phabricator.fb.com/P12855495

With this and @simons's upgrade to guava 17, we can now safely
re-enable logging for com.google.common.util.concurrent.

Test Plan:
Introduced build error. Ran 'buck build buck'. Previously,
we got log spew (P12855495). Now, we don't.

Depends On D1410752
Parse java utils log to collect debug rule keys in perf test.

Summary:
And raise an exception with some useful debug info if we cannot find a
rule key.

Test Plan: sandcastle
Manually ignore tests annotated with @Ignore when doing dry-runs

Summary: `--dry-run` wasn't actually ignoring tests annotated with `@Ignore`.

Test Plan: Included an integration test plan!
Introduce android_build_config() and drop support for build_config().

Summary:
**The problem:**
The standard Android/Gradle build tools from Google provide a `BuildConfig` class with global
constants (such as `DEBUG`), which are convenient for development. In Buck, such a class
would have to be a leaf node within the DAG because it could be a dependency of
any `android_library()` rule in the graph.

If these constants were declared as constant expressions (see JLS 15.28), then their values could be
inlined by `javac`. This would be problematic because if you had two `android_binary()` rules
with identical dependencies, save the value of `BuildConfig.DEBUG`, then you would have to
compile all of the intermediate dependencies twice: once with `BuildConfig.DEBUG` set to `true`
and once with it set to `false`. This seems wasteful.

**Our solution:**
We introduce a special rule, `android_build_config()`, which generates a `BuildConfig.java` file
similar to the one generated by Gradle and compiles it. The output of `android_build_config()`
is a JAR containing the compiled `BuildConfig.class` file. It is recognized as a Java rule by
Buck, so it is designed to be listed in the `deps` of a Java rule, such as `java_library()`
or `android_library()`. That is, the `srcs` of such a Java rule can compile against the `BuildConfig`
class generated by the `android_build_config()` when listed in its `deps`.

However, `android_binary()` performs a special transformation on all `android_build_config()` rules
on its transitive classpath. Specifically, each `BuildConfig.class` that was originally destined
for the `classes.dex` in the APK is replaced with a new implementation with the following differences:

* The value of each field is a constant expression.
* Field values are set to reflect the attributes of the APK to be built by the `android_binary()`. Currently, our `BuildConfig` has only two fields: `DEBUG` and `IS_EXOPACKAGE`. The values for each map to the corresponding value for the `android_binary()` argument.

This means that two `android_binary()` rules that differ only by the values
of `package_type = 'DEBUG'` vs. `package_type = 'RELEASE'` can be built simultaneously very
quickly as their compilation steps will be shared and will differ only in their packaging of the APK.
There is a concrete example in the Javadoc overview for `AndroidBuildConfig.java`.

Note that this replacement of the `BuildConfig.class` files happens before all of the `.class` files
are passed to ProGuard if ProGuard is enabled.

There primary downside to this approach is that `javac` will not be able to do the same inlining
that it could do if the `BuildConfig` fields were constant expressions at compile time. We recommend
leveraging ProGuard to do this inlining (which most developers already do for release builds) if
this is important to you.

We believe this drawback is small compared to the savings in build times. This enables our build
graph to remain clean from the perspective of developers looking at `BUCK` files.

**Diff overview:**
The new `android_build_config()` rule is much more powerful than the previous `build_config()` rule,
so this diff removes support for `build_config()`. It namespaces the new rule with `android_` because
it is designed to interact with `android_binary()` in a special way.

As such, the old `BuildConfig.java` and `BuildConfigDescription.java` files have been migrated
to `AndroidBuildConfig.java` and `AndroidBuildConfigDescription.java`, respectively.

The logic for generating a `BuildConfig.java` file for Android is handled by `BuildConfigs.java`.

Executing `android_build_config()` involves two important steps: generating `BuildConfig.java` and
then compiling it. As such, Buck uses graph enhancement to divide `android_build_config()` into
two `BuildRule`s under the hood: `AndroidBuildConfig` and `AndroidBuildConfigJavaLibrary`.
You can see this construction in `AndroidBuildConfigDescription`. Moving the compilation into its
own `AndroidBuildConfigJavaLibrary` rule makes it easier to exploit the existing logic
around `JavaLibrary` rules in Buck.

Test Plan:
Added tests, as appropriate:

* Created `AndroidBuildConfigIntegrationTest` as an integration test to verify that `android_build_config()` makes it possible to compile against the appropriate `BuildConfig` class from a `java_library()` rule.
* Updated `AndroidBinaryGraphEnhancerTest` to verify the new logic in `AndroidBinaryGraphEnhancer`.
* Created `BuildConfigsTest` to verify the new `BuildConfigs` class.
* Created `AndroidBuildConfigJavaLibraryTest` to verify the new `AndroidBuildConfigJavaLibrary` class.

Manual testing:
* Created a new project via `buck quickstart`.
* Created an `android_build_config()` and made `//java/com/example/activity:activity` depend on it.
* Added `Log.e("MYTAG", "BuildConfig.DEBUG is " + BuildConfig.DEBUG)` to `MyFirstActivity.onCreate()`.
* Ran `buck install --run app` and verified that `E/MYTAG   ( 5922): BuildConfig.DEBUG is true` was in `adb logcat`.
* Changed the `package_type` of the `android_binary` to `'RELEASE'` and re-installed the app.
* Verified that `E/MYTAG   ( 6923): BuildConfig.DEBUG is false` was in `adb logcat`.
No longer retain a reference to the `ServiceManager` in `Main.java`.

Summary: Eclipse was flagging `manager` as a field that was never read.

Test Plan: Yellow warning icon goes away in Eclipse.
Filter out the declared deps of AndroidManifest.

Summary:
Why? - refer to docs above `AndroidManifestDescription.Arg#deps`.

I was trying to avoid this somewhat gross approach, but that didn't go so well.

Test Plan:
buck test --all
Wait for robolectric tests this time.
Change AppleBuildRule interface to abstract classes.

Summary:
Currently Apple build rules inherit from AbstractNativeBuildRule and implement AppleBuildRule,
leading to a lot of duplicated boilerplate as they're all handled pretty much the same. This changes
the AppleBuildRule interface to two abstract classes and has them all inherit from those instead, to share
the boilerplate implementations.

Test Plan: buck test --all
Deduplicate generateIosTestTarget.

Summary:
generateIosTestTarget is almost exactly the same as generateBinaryTarget.
This factors out the common parts by adding a new parameter to generateBinaryTarget
to format the product output name.

Test Plan: buck test --all, Tools/buck/buck-project.py
Add support for info_plist to macosx_framework.

Summary:
Currently ProjectGenerator is ignoring the infoPlist field on
MacosxFramework. This adds support to it by treating it the same way as in
binaries.

Test Plan: buck test --all
Deduplicate generateMacosxFrameworkTarget.

Summary:
generateMacosxFrameworkTarget is almost exactly the same as generateBinaryTarget.
This factors out the common parts by having generateMacosxFrameworkTarget call
generateBinaryTarget.

Test Plan: buck test --all, Tools/buck/buck-project.py
[buck/ios] add new ios_postprocess_resources rule

Summary:
This is necessary to finish converting an iOS application to buck.
The application currently has a run script build phase which runs after resources
are copied to the app bundle, and which pngcrushes all the copied PNGs.
We don't apply that transformation to PNGs in master, because it would make
them un-openable in Preview.app or other image viewing applications, which we don't want to break.
Currently we can't support this with buck, since buck for iOS
places all 'run script' build phases before the 'copy resources' build phase.

Sidenote about why we need a custom script for this:
Normally projects can rely on Xcode to pngcrush these resources as they
are copied to the app bundle, but Xcode doesn't touch resources inside
of bundles that are copied over, which is true of many of our resources.

The two approaches we can take to fixing this are either:
— use a genrule as it is intended to generate pngcrushed resources when building, and
have xcode copy those to the app bundle instead. this would be a fairly
invasive change, and would require either:

— all libraries are aware of PNG crushing and use a genrule to produce
their bundle. This would also require changes to buck for iOS, since right now
our genrule support isn't fully baked (genrule's of dependencies aren't
considered when generating projects).
— ios_resource copies resources to a separate 'generated resources'
folder, which is what the 'copy resources' build step actually copies to
the app bundle, and ios_resource automatically applies PNG crushing to
resources in the 'generated resources' folder.

— the second approach, which is the one I went with here, is to add a
new buck rule specifically for iOS (I named it
`ios_postprocess_resources`) that provides the ability to generate a
'run script' build phase which happens after resources are copied to the
app bundle. I think this is much less invasive and doesn't
fundamentally change how genrule's work with buck for iOS, which was the
issue with D1396857.

Test Plan:
added a unit test which confirms the rule creates a run
script build phase and places it after the copy resources step.
[buck] fix apple BUCK file

Test Plan:
wait for async tests to finish. ran ./bin/buck test --all
locally, it no longer complained about Genrule not being defined
Fix AndroidInstrumentationApk graph enhancement.

Summary:
I managed to screw this up in my diff merging build rules and buildables.
The instrumentation apk was not depping the apk under test as a result.
This fixes it.

Test Plan: buck build //perftests:perftests_release
Mark BuildRule#getPathToOutputFile() as @Nullable.

Summary: I missed this when I merged Buildable and BuildRule.

Test Plan: sandcastle
Don't share java.io.tmpdir

Summary:
Another diff to support the TestPilot pattern where:
* TestPilot runs a single `buck test --dry-run ...` to get a list of tests; then
* TestPilot launches multiple concurrent `buck test --one-time-output --filter <test>` processes.

{D1371090} used the `--one-time-output` option to have unique subdirs of `buck-out` for each individual `buck test` process.  This diff gives each `buck test` process its own `java.io.tmpdir` as well.

I'm pretty sure this is what's causing errors like the one shown in P13017522.

Test Plan:
Nothing automated :(

I tested this by inspecting the output of `getPathToTmpDirectory` with the debugger, with and without the `--one-time-output` option.

Also [[https://our.intern.facebook.com/intern/testinfra/testrun/15095243 | this test run]] shows the fix is eliminating my APK jarsign woe.  The `SHjsign` and `SHadb` errors went from 14-per-run to 0-per run, as summarized in this extremely obscure paste: P13017798.
Remove dead code.

Test Plan: buck test --all
Remove unnecessary addCoreDataModelBuildPhase call.

Summary:
This call doesn't do anything as there's another call right
before it in generateBinaryTarget.

Test Plan: buck test --all, Tools/buck/buck-project.py
Introduce new verbose log level

Summary:
Previously, the logging facade from Airlift exposed four log
levels: error, warning, info, and debug.

I'd like to match fbandroid and fbobjc by adding a "more verbose than
debug" level, conveniently called "verbose". By default, this will not
be written anywhere, but engineers working on their own systems can
enable verbose logging for their areas in .buckconfig.local.properties.

Test Plan:
Changed a log message to verbose, confirmed it wasn't logged
until I enabled FINER level logs.
Easy: Change RuleKey logging to verbose level

Summary:
Our logs are filled with tons of ultra-verbose RuleKey
debug statements, even for rules we don't execute.

This changes RuleKey's logs to verbose level so we'll only see
them if we explicitly enable them.

Depends On D1425020

Test Plan:
buck build buck. Before, it spewed RuleKey logs to
buck-out/log/buck-*.log. Now, it doesn't.