Should promise UTF-16 surrogate pairs handling

Time to face this. After manual inspection all -characterAtIndex: calls seem to be fine, but there are at least a couple of places where string length are assumed to be equal to character count. Some examples:

1. Length of a single-character string are assumed to be 1. For example, NSMakeRange(location, 1) is used to acquire the substring range of it in a string. Should use str.length instead.
2. -length is used as character count in the string. This is a problem for the word counter, for which trimmedDocument.length is used to count characters. Should use substring enumeration with NSStringEnumerationByComposedCharacterSequences to count that manually instead.

There are likely more. Things in NSDocument can be inspected manually (not that much text processing logic there), but unit tests are needed in other classes.

Edit: NSLayoutManager’s glyph API might also be useful. I suspect that would be slower, though, since they usually generate NSGlyph instances. Maybe some benchmarking is needed?

Inspect the text-processing logic in NSDocument and the other classes containing NSMakeRange(..., 1) or -length character-count assumptions. Add unit tests for surrogate pairs and composed character sequences, and use the tests to identify remaining incorrect counts; done means the affected cases handle UTF-16 strings correctly and the test suite passes.