Compiler generates invalid patch files when the patch location is in a subdirectory

### What version of Error Prone are you using?

2.3.1

### Does this issue reproduce with the latest release?

Yes

### What did you do?

Following the instructions [here](http://errorprone.info/docs/installation#java-8):

```
$ java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
```

```
$ curl https://repo1.maven.org/maven2/com/google/errorprone/error_prone_ant/2.3.1/error_prone_ant-2.3.1.jar > error_prone_ant-2.3.1.jar
$ echo 'public class Foo { void bar() { new RuntimeException(); } }' > Foo.java
$ mkdir subdir/
$ java -Xbootclasspath/p:error_prone_ant-2.3.1.jar \
com.google.errorprone.ErrorProneCompiler Foo.java \
-XepPatchChecks:DeadException -XepPatchLocation:`pwd`/subdir
```

### What did you expect to see?

I expected ErrorProne to generate a valid patch file.

### What did you see instead?

ErrorProne produced the following output, as expected:

```
Foo.java:1: warning: [DeadException] Exception created but not thrown
public class Foo { void bar() { new RuntimeException(); } }
^
(see http://errorprone.info/bugpattern/DeadException)
Did you mean 'public class Foo { void bar() { throw new RuntimeException(); } }'?
Changes were written to /path/to/subdir/error-prone.patch. Please inspect the file and apply with: patch -p0 -u -i error-prone.patch
```

However, `subdir/error-prone.patch` contains:

```
--- ../Foo.java
+++ ../Foo.java
@@ -1,2 +1,2 @@
-public class Foo { void bar() { new RuntimeException(); } }
+public class Foo { void bar() { throw new RuntimeException(); } }
```

Note that the paths in the `subdir/error-prone.patch` file contain `..`. As a result, applying the patch results in an error:

```
$ cd subdir/
$ patch -p0 -u -i error-prone.patch
patch: **** rejecting file name with ".." component: ../Foo.java
```

(Invoking `patch -p0 -u -i subdir/error-prone.patch` from the original working directory results in a different error since the files are resolved from the CWD.)

GNU `patch` started emitting this error in 2010 as a result of [CVE-2010-4651](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4651). `/usr/bin/patch` on macOS has been disallowing this case for longer than that. In general, it seems like it's not valid for patch files to contain paths with `..`.

One solution here would be to simply use absolute paths in `error-prone.patch` files.