Make osc.readString not fail on very large strings

[okofish]

Previously, osc.readString used String.charCodeAt.apply with a TypedArray consisting of the entire OSC argument. This would fail with a RangeError on very large (>~60k-100k bytes) string arguments, as it would hit the limit on the number of arguments to a function.

This PR checks for the existence of Buffer (Node.js/Electron) or TextDecoder (modern browsers) and uses them to decode the TypedArray if available. If not, it will use charCodeAt as before, but it applies it to the array in chunks so as not to hit the argument limit. When using Buffer or TextDecoder, this has the added benefit of properly decoding multi-byte Unicode characters. Killing two bugs with one patch!

I added a test for large string behavior but not for multi-byte character decoding, as this is not necessarily universal behavior. I always have issues with Electron and node-serialport, so I would appreciate if someone else could run the Electron tests.

[colinbdclark]

Thanks for the PR, @okofish. I'll take a look as soon as I have some spare time!

[okofish]

Hey, did you get a chance to look at this yet?

[colinbdclark]

Hi @okofish, I'm so sorry it took me so incredibly long to look more closely at this pull request. Your PR looks good; I've done some minor refactoring to your code. Does this seem reasonable?

Do you think we should be worried about the asymmetry of supporting UTF-8 characters when reading OSC messages but not while writing them? Should we be using the equivalent TextEncoder approach in osc.writeString?

I'm tempted to go ahead and merge this and not worry too much about it for now, but wanted to gather your thoughts first.

Again, apologies for the delay and thank you very much for submitted this PR, I appreciate it.

[okofish]

Refactors look fine. I would tend to think that TextEncoder in osc.writeString would be a good idea. Incidentally, I haven't tested this but Node.js v8.3 (released after I made this PR) seems to have TextEncoder and TextDecoder available under the util module, and in the just-released v11 they were made globals. It would make sense to use TextEncoder/TextDecoder by default if they're available as globals or from util, then Buffer, and finally fromCharCode. But feel free to merge as-is if you don't want to make this change :)