Only update the cursor selection once per mouse-down

In Chrome, right-clicking repeatedly generates both a contextmenu AND
a mouseup event for subsequent clicks. E.g. a sequence of right clicks
generates:
1st - mousedown, contextmenu
2nd...nth - mousedown, contextmenu, mouseup

This causes problems when clicking on images as the selection is
immediately reset after being processed by the first context menu,
causing the subsequent mouseup event to try and reset the cursor
selection *again*.
Hide the cursor anchor element

This is not a visible element. It is used only to track selection
ranges inside the document.
Add some additional documentation to mouse click handling
Maintain selection when right-clicking on a range that ends at an image

On OSX, right-clicking on an image at the end of a range selection will
hit this particular branch. The image should remain selected if the
right-click occurs on top of it as technically it's the same behaviour
as right clicking on an existing text selection.
Fix packextension.js: runtime.readFile no longer returns a buffer for NodejsRuntime
Properly register/unregister components for ODT/ODP/ODS in FF-Add-on
Unbreak "download this document" button in FF extension

getUserData/setUserData was deprecated and is no longer available in latest
Firefox (e.g. 27.0). Using e.g. the dataset property instead did not work
for storing callback methods. As currently only one async requests without
a callback are used, any support for callbacks or sync requests was simply
removed. Proper implementation delayed till callbacks or sync requests are needed.
Rename Firefox add-on to "ODF Viewer"
Use new ids for the components of the FF extension

to avoid conflicts with the ids of the old version
where the components where not properly unregistered
Resynchronize the window selection on any local cursor update

The window selection should be synchronised every time the local user's
cursor is moved. When the local user's selection is modified using the
keyboard, the event trap never loses focus, so the focus event is not
fired, meaning the window selection was not being reset.

Now, the local cursor's update event is directly subscribed to, and if
the document has focus, the window selection is reset. Note, if the
document does not have focus, no reset will occur to prevent focus
stealing.

Fixes a regression introduced in 8de8dde.
Merge pull request #475 from kossebau/restoreFirefoxAddon

Restore Firefox Add-on
No line-ending enforcements for imported external files
Switch eol to use native rather than lf
Unix line-endings for playbook/ext/blackberry.custom.filereader/library.xml
Merge pull request #518 from kossebau/noLineendConversionForImportedFiles

No line-ending enforcements for imported external files
Force the entire step cache to be revalidated after operation tests

The step cache verification only ensures the cache is valid when step
conversion is requested. Therefore, to force the cache to recheck
after completing the test, the maximum available step is requested.
Add failing operation test showing caching issue
Move ODT-specific logic out of StepsCache into the steps translator

This is purely a refactor laying the groundwork for fixing the failing
operations tests. There are no expected functional impacts.
Update the StepsCache when restoring a bookmarked position

Whenever any iteration occurs, the cache needs to be updated so damage
can be repaired. This particular change fixes an issue where restoring
from the root bookmark ends up iterating up to the first damaged
paragraph bookmark, which should cause the paragraph bookmark to be
repaired.

This requires consumers to be able to mark ALL current bookmarks as
damaged, which is now achieved by passing in "-1" as the inflection
step to the damageCacheAfter(…) call.

Fixing this bug has exposed another existing issue that potentially
re-orders bookmarks that share the same step. This uncovered problem
will be addressed in a subsequent commit.

Fixes the cache corruption aspect of issue #503
Add StepCache support for multiple bookmarks with the same step number

It is valid for multiple bookmarks to share the same step number if
the user of the steps cache does not have a perfectly granular position
filter.

For example, paragraphs within a tracked changes block are not valid
steps according to the TextPositionFilter. This means all these
paragraphs stack up on the same step.