Split up mouse handling so that overriding default mouse behavior does not affect other default behavior

[JordanMartinez]

I'm not going to merge this just yet. I'm going to write some TestFX tests that simulates the expected behavior of the mouse behavior before this PR's changes were added to it. Then I'll rebase the work here (and clean it up) to insure that the new code works exactly as the previous code.

[JordanMartinez]

Let me explain this PR.

The default mouse behavior accounts for

• a single, double, or triple click
• creating a new selection on mouse drags
• dragging the selected text to a new location
• and autoscrolling when a drag goes beyond the area's bounds.

So, I've narrowed the EventPatterns where I thought appropriate (e.g. only the primary button is presed, or any time the primary button is pressed), so that one can add additional behavior without it screwing up the default behavior.
Some behavior, such as "the user presses the mouse over the selected text, drags it to a new location, and releases the mouse" cannot be overridden without screwing up the default behavior. As such, hooks like onSelectionDrop (which is what is called in the aforementioned scenario) are used.
Lastly, when the developer wants to add additional "drag" behavior, they may also want the auto-scrolling feature to work. So, I reconfigured the behavior so that they can execute their desired behavior via InputMap#process, which returns InputHandler.Result.PROCEED, before the event reaches a "catch all" InputMap that handles the auto scrolling correctly before consuming the event.

Realizing that some developers may not want the auto scroll feature to occur on some drag events, I think I should add another flag to the area that they can switch on/off to control when that happens.

[JordanMartinez]

Ok, the flag has now been added.