support snakeyaml UnicodeReader

[pjfanning]

• jackson-dataformat-yaml has its own UTF8Reader but snakeyaml has its own UnicodeReader
• there is some concern that our UTF8Reader may not handle 3 byte chars (UTF8Reader throws"Need to move partially decoded character; buffer not modifiable" when read only one chinese char #497)
• could we add an option (non-default) that allows users to opt into using the snakeyaml one instead?
• I can implement it if it is agreed that it is useful

[cowtowncoder]

I'd be -1 for adding configurability at this point.

The original reason for UTF8Reader use has been performance (esp. for smaller documents). If performance of UnicodeReader was adequate (... I have some concerns since SnakeYAML decoder is rather inefficient) would be ok with change.

But we still need to resolve #497 for CSV no matter what so would ideally target that first.

[pjfanning]

I understand that CSV still has the 497 issue but since the UTF8Reader class is copied into the yaml, csv and toml modules there is a risk that all 3 are still affected in some cases. I might try to set up some jmh testing of the UTFReader against the Java InputStreamReader to see which is best. Ideally, Jackson shouldn't need special UTF8 decoding. We've seen with number writing that Java team sometimes does try to fix their perf issues.

[cowtowncoder]

True, ideally we would not need plain UTF-8 decoding readers (as opposed to JSON codec where combination of decoding and tokenization is bigger win and makes more sense).
As I recall, the main challenge with JDK one was simply its allocating big, non-reusable decoding buffer.

I'd be bit more cautious about using UTF-8 reader from SnakeYAML fwtw; JDK version less so.