Disable caching in tools/serve. Fixes #236.
Testing: enhance MockSelection to provide a true commonAncestorContainer

Earlier, the commonAncestorContainer was always set to the root of the
whole fixture. However, this does not correspont to the specification
of Range.commonAncestorContainer and what real browsers do.

I have adjusted the mock object to behave more like real browsers.
Added a bunch of Range test cases

to test for the problem causing #235.
(This will break the tests, and it's intentional, since the code is broken, too.)
Tighten/fix up range normalization

This is next attempt at fixing this long-standing issue.
Some background:

When we are normalizing a browser range, we must find a text node and offset
to point to, even if the browser range is pointing to some other (nearby)
node element. (p, div, br, img, whatever).
To do this, we must do some DOM crawling.

Earlier we were trying to take some shortcuts, but that failed on some crazy
page structures. Now I added full recursive crawling ability to locate the
wanted text nodes.

This fixes all the failing Range test cases, and also fixes #235.
Work around test failure caused by PhantomJS bug
Work around test failure caused by PhantomJS bug
Added test cases for Util.contains.

You can use the first test case ('should return true when called on itself')
to showcase the problem with the .contains() implementatin shippen with PhantomJS.
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.)
Added link to PhantomJS issue
Added link to PhantomJS issue
Merge branch 'master' of https://github.com/okfn/annotator
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.)
Merge pull request #238 from okfn/range-normalization-fix

Range normalization fix
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