I've found cases where `MediaType::toString` generates erroneous results.

One case is when the `MediaType` instance has a parameter of an empty value. This can happen when calling `withParameter("foo", "")`, or parsing `text/plain; foo=""`. When the parameters are later joined, the value is erroneously matched as a token instead of being quoted (as tokens cannot be empty). This will lead the following to throw `IllegalArgumentException`: 
```java
MediaType type1 = MediaType.parse("text/plain; foo=\"\"");
MediaType type2 = MediaType.parse(type1.toString()); // Trying to parse 'text/plain; foo=' will fail
```
 I think [this line](https://github.com/google/guava/blob/5a8f19bd3556012ed9e65cd4268a85ddde95733f/guava/src/com/google/common/net/MediaType.java#L1091) should first check if the string is empty before matching against `TOKEN_MATCHER`, or maybe just return the literal `"\"\""` on that case to avoid the `StringBuilder` allocation.

Another case is when parameters are set explicitly using `withParameter[s](...)`, where parameter value[s] contain non-ASCII characters. For example this will also throw `IllegalArgumentException`:
```java
MediaType type1 = MediaType.create("text", "plain").withParameter("let_me_in!", "\"جوافة\"");
MediaType type2 = MediaType.parse(type1.toString()); // The tokenizer will fail to consume QUOTED_TEXT_MATCHER
```
I don't know whether this is the intended behaviour or not but `MediaType::toString` can be used in HTTP header values which shouldn't contain non-ASCII octets. IMHO `normalizeParameterValue(...)` should validate the value against the `ascii()` matcher.
public final class ByteStreams {
  private static final int BUFFER_SIZE = 8192;
  
  static byte[] createBuffer() {
    return new byte[BUFFER_SIZE];
  }
  /**
   * There are three methods to implement {@link FileChannel#transferTo(long, long,
   * WritableByteChannel)}:
   *
   * <ol>
   *   <li>Use sendfile(2) or equivalent. Requires that both the input channel and the output
   *       channel have their own file descriptors. Generally this only happens when both channels
   *       are files or sockets. This performs zero copies - the bytes never enter userspace.
   *   <li>Use mmap(2) or equivalent. Requires that either the input channel or the output channel
   *       have file descriptors. Bytes are copied from the file into a kernel buffer, then directly
   *       into the other buffer (userspace). Note that if the file is very large, a naive
   *       implementation will effectively put the whole file in memory. On many systems with paging
   *       and virtual memory, this is not a problem - because it is mapped read-only, the kernel
   *       can always page it to disk "for free". However, on systems where killing processes
   *       happens all the time in normal conditions (i.e., android) the OS must make a tradeoff
   *       between paging memory and killing other processes - so allocating a gigantic buffer and
   *       then sequentially accessing it could result in other processes dying. This is solvable
   *       via madvise(2), but that obviously doesn't exist in java.
   *   <li>Ordinary copy. Kernel copies bytes into a kernel buffer, from a kernel buffer into a
   *       userspace buffer (byte[] or ByteBuffer), then copies them from that buffer into the
   *       destination channel.
   * </ol>
   *