Find bad DateTimeZone.forID / TimeZone.getTimeZone parameters

@kluever found ~20 files with occurrences of "America/Los Angeles" (rather than "America/Los_Angeles"). I see ~15 with "America/New York."

There are at least two ways to approach this:
- In about 1/3 of these cases is the string literal used directly as a parameter to one of the standard "create a time zone" methods. For those cases, we can actually call the method at compile time (or otherwise maintain a list of known good time zones) -- _if_ we trust for the data available to Error Prone to match the data available at runtime. The upside here is that we catch not only space-underscore mixups but also misspellings.
- Regardless of how it is being used, "America/Los Angeles" is unlikely to be correct. We could error out on all strings with apparent space-underscore time-zone mixups (or on all strings with an edit distance close to a known time zone -- edit-distance support may show up in Guava in 2016, if that helps).

(Does JDK8 have any new time-zone APIs? Maybe `ZoneId.of`?)