Micro-optimization: calculate target value before cycle
Be more conservative when splitting text elements

Some browsers have the habit of splitting off 0-length text nodes,
when they are told to do so. (Thus littering the DOM with useless elements.)
Therefore, let's try to be more conservative when slicing and dicing elements.

(This modification only adds one extra condition,
and a bunch of explanatory comments.)
Fix an off-by-one problem with range normalization.

When creating a BrowserRange from a SerializedRange (for normalizing),
and specifying the start (with a node/offset pair),
never use the very end of a text node; always use the start of the next one.

Specifying the end of a text node (where there are no more characters left)
can have unwanted consequences.

(I have added test case to showcase the problem.)
testing: don't mess up the Selectino API
Add utility to read out the text of a range using the browser selection API
Enhanced test case to detect off-by-one errors on range normalization.

Now the test case also analyzes the created range by reading it out
via the browser selection API. This is needed to expose some problems
that are hidden otherwise. (Like whitespace sneaking into the selection,
because we are not selecting the right text nodes.)
Attempt to clarify range logic with comments

I switched to using a strict greater than comparison here because
it privileges the start offset: rather than adding 1 to the start,
we remove 1 from the end which, to me, is a clearer reflection of
what's going on. The Range specification describes the endOffset as
the boundary offset, therefore excluding the character at that index.
Replaced .data with .nodeValue for consistency
Fixed typo
Merge pull request #241 from okfn/contributions-from-h

bug-fixes and small improvements to range