Fix for issue #4: reported click count can be 0 under some situations

According to the specs, the click count is 0 if the user moves the
mouse between mousedown and mouse up. The definition of "moved" seems
a little loose, meaning there are still some unfixed side-effects (e.g.,
double-click & drag will reset back to word selection).
Move DOM-related comparePoints into common DomUtils
Allow double-click drag selection changes

Previously, the selection was being reset back to the word-boundary
of the word that contained the cursor at the time of the double-click.

Now, the browser selection is always updated, with additional logic to
expand the selection to the nearest boundary based on the double or
triple-click status of the event.
Jump to next valid position when setUnfilteredPosition is passed a child of an invalid parent

PositionIterator.setUnfilteredPosition API doc report that when given
a forbidden position, the iterator jumps to the next visible position.
Add code to cover a missed corner case if the container was a child of
a forbidden parent (or grand parent) node.
Merge pull request #9 from peitschie/ff-clickfixes

This works well and while fixing #4, also fixes an issue where mousedrawn multi-paragraph selections could not be restyled. Thanks, merging. :+1: