Java bindings assume strings are utf-8

Despite the watchman docs noting that in bser strings may not be utf-8, and are unknown encoding due to the nature of file system apis, currently the java deserializer assumes utf-8:

https://github.com/facebook/watchman/blob/master/java/src/com/facebook/watchman/bser/BserDeserializer.java#L236

This causes exceptions when some rogue process (I haven't been able to find out which yet), writes non-utf-8 file names:

```
Caused by: java.nio.charset.MalformedInputException: Input length = 1
at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:274)
at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:813)
at com.facebook.watchman.bser.BserDeserializer.deserializeString(BserDeserializer.java:236)
at com.facebook.watchman.bser.BserDeserializer.deserializeRecursiveWithType(BserDeserializer.java:332)
at com.facebook.watchman.bser.BserDeserializer.deserializeTemplate(BserDeserializer.java:302)
at com.facebook.watchman.bser.BserDeserializer.deserializeRecursiveWithType(BserDeserializer.java:338)
```

I suppose this is expected, but it blows up the entire `deserialize`, so it's not really easy/possible for me (AFAICT?) to recover from this. I have to stop my process, go find the rogue file, delete it, and then restart the process.

Is there an alternative way for `BserDeserializer` to handle this that would let me continue processing? Maybe just log an error and return `null`? I know that is also surprising, but knowing name is nullable is at least a check I can perform.