Capture events during buck tests.

Summary:
Add a facility to capture all buck events during a test run, and store them in
`com.facebook.buck.testutil.integration.ProjectWorkspace.ProcessResult`.

Test Plan: Used in another diff.
Test for bug in assumption-violations reporting.

Summary:

Test Plan: Run it!
Run `buck test --all` after `ant test` in automation and haltonerror in Ant.

Summary:
Currently, the Ant test output is very hard to read.
Using haltonerror will give us less signal when a test fails,
but at least it will be easier to find the failing test.

Test Plan: Sandcastle
Switch to the SVG Travis badge.

Summary: It's prettier: http://i.imgur.com/HvaD3JJ.png

Test Plan: Pushed a test branch to GitHub to get that screenshot.
Basic support for FakeProjectFilesystem.newFileOutputStream().

Summary:
This will be really useful for an upcoming test. I am sure I am missing a bunch
of cases, but I am guessing this is good enough for tests? Thoughts?

Test Plan: Added a new test.
Fix spelling in an error message in exopackage.

Test Plan: Buildbot.
Test script for the exopackage installer.

Summary:
An upcoming diff will make some changes to the installer to improve
device compatibility.  This is the script that I used to test it.  It's
not an exhaustive test of exopackage (for example, it doesn't verify
that we don't re-install the apk on a Java-only change), but it does
test the happy path of doing a clean and incremental install and verify
that the code changes.

There's a very small app in testdata that logs a string on startup.  The
script builds it, installs it, captures logs, edits it, builds it,
installs it, captures logs, then verifies that both logs are correct.

There's a wrapper script that runs the test serially on all connected
devices, then prints a result summary.

Test Plan:
Ran it on a bunch of devices.  Saw mostly successes, but some failures,
which were properly reported.
Fix some warnings in the exopackage agent.

Summary: The sprintf one might actually break 64-bit builds.

Test Plan: Exopackage test.
Improve exopackage device compatibility.

Summary:
A few things here, but they're kind of intertwined.

- The PIE executable was segfaulting on Gingerbread.  We didn't notice
  sooner because the PIE diff didn't bump the agent version, so devices
  that already had the old agent kept working.  Revert the PIE change.
- Use the Java agent on post-KitKat devices because they only support
  PIE.
- Implement a "mkdir-p" command in the agent for devices where mkdir
  doesn't recognize -p.  I did this in both the native and Java agents,
  but the Java one is kind of useless because it forces strict
  permissions.
- Use "mkdir -p" instead of the agent if we're not using the native
  agent to avoid the permissions problem.  Yes, it's a hack.
- Bump the agent version code and rebuild the binary.

One configuration breaks this installer: an AOSP build between KitKat
and the L preview that claims to be 4.4.x but can't run non-PIE
binaries.

Test Plan:
Built the agent on my host and ran mkdir-p a few times under strace.  It
was similar to the real mkdir.

Ran the exopackage test script on the following devices:

- Galaxy Pocket Neo (Android 4.1, sometimes has problems with starting
  the exopackage apps)
- HTC One X (Android 4.0, had agent segfaults)
- HTC Evo 4G (had agent segfaults)
- Galaxy S (mkdir didn't understand -p, and had agent segfaults)
- Nexus 5 with L preview (can't run non-PIE binaries) (note that this
  required me to manually approve the installation on the device)
- Nexus 5 with AOSP build between KitKat and L.  This failed.
- Genymotion 2.3 and 4.4.
- Emulator 2.3 (ARM) and 4.3 (x86)
Make tests more reliable.

Summary:
Print InterruptedException stack traces to ProcessResult
error stream, so that tests can test for interruption rather than
relying on timeouts, making them more resilient. Reset thread
interrupted flag after tests to increase test isolation. Check for
overflow when waiting for file changes in tests to detect cases where
changes may be missed.

Test Plan: buck test --all
Update android_build_config() to support custom values.

Summary:
Previously, `android_build_config()` generated a `BuildConfig`
file with only two constants: `DEBUG` and `IS_EXOPACKAGE`.
This diff introduces a feature that enables developers to include
additional, custom fields to `BuildConfig`. Like `DEBUG` and `IS_EXOPACKAGE`,
the values of these fields will not be constant expressions at compile
time, but can be constant expressions before ProGuard is run when
packaging the `BuildConfig.class` into an APK.

Specifically, this diff adds two optional arguments to `android_build_config()`, `values`
and `values_file`. These arguments can be used to specify additional fields (and values)
for the generated `BuildConfig` class. The `values` argument should be used when
the values are static and can be specified directly in the build file. In contrast, the
`values_file` argument should be used when the values are determined by the output
of some other build rule.

If specified, `values` is a list of strings that match the pattern:

  <JavaType> <JavaVariableName> = <LiteralValue>

For example, the following would be a valid declaration of `values` in a build file:

```
android_build_config(
  name = 'build_config',
  package = 'com.example.buck',
  values = [
    'int VERSION = 1234',
    'boolean IS_A_GOOD_FIELD = true',
    'String APP_ID = "vcebelutvgnvljrnnvuurudbbknrbfij"',
  ],
)
```

If the `values_file` is specified, it must identify a file whose contents are lines
like those in the `values` argument in a build file. For example, valid content of
a `values_file` would be:

```
int VERSION = 1234
boolean IS_A_GOOD_FIELD = true
String APP_ID = "vcebelutvgnvljrnnvuurudbbknrbfij"
```

If both `values` and `values_file` declare fields with the same name, the values
in `values_file` take precedence.

To override any of the values for the fields in an `android_binary()` that transitively
depends on the `android_build_config()`, specify at least one of the `build_config_values` or
`build_config_values_file` arguments.
Like `values`, `build_config_values` must specify a string array while
`build_config_values_file` must specify a file whose contents match the field declaration
format. Not all fields must be redefined to use this feature.

Note that both `values_file` and `build_config_values_file` are `SourcePath`s so they can
either be static files in version control, or files generated from another build rule.

This diff also updates the public documentation for `android_build_config()`
to explain this new feature.

Test Plan: Updated corresponding unit and integration tests.
Ensure `buck project` works when the binary_jar of a prebuilt_jar is a genfile.

Test Plan: Added test to ProjectIntegrationTest.
Update Exopackage "non-working devices" list.

Summary: Fixed some bugs!

Test Plan: Soyweb.
Update URLs in Exopackage article to point to facebookarchive.

Test Plan:
Clicked links in soyweb.
Ran the clone.