Dragbox resizing when edges are dragged

(opening this on `develop` branch)

This PR implements resizing a dragbox by dragging its edges when it's drawn on screen. The cursor changes appropriately even on first draw.

http://jsfiddle.net/552z0h27/

There are some questionable areas I'd like feedback on, specifically on how organized code looks and its simplicity. The code added to `XYDragBoxInteraction.ts` seems like a lot for example.

The API for dragging events still works like before, the callbacks the start and end points, even on resizing even if the dragbox is not bounded by those points. For that, there is `DragBoxInteraction.selection` which is a `SelectionArea`.

`DragBoxInteraction.isResizing` is public, I thought it'd be useful for the user rather than them keeping track themselves. There are some use cases where a user might want to load data for example only on `dragend` and on `drag` only when `isResizing` is `true`, but not on first draw.

There is still an error when dragging from the very edge, it sometimes draws a new box instead of resizing. I suspect this happens because the d3 `drag` events only provide `d3.event.x` and `d3.event.y` on the first `drag` event, instead of on `dragstart`. On `drag` the user will have already moved at least a pixel, making the mouse position not close enough for a resize.

We can "fix" this by binding for the click event, and setting the origin early, inside of `DragInteraction._dragstart()`. Or by lowering the padding at which the cursor is changed, but keeping it slightly bigger from actually checking if it's close enough for resize.

Thoughts?
Setting state at some point is necessary yes, but can it be set in a place that's not inside a getter function?   Hints I can generate from the code is if you order your code like so
var leftResult...
var rightResult...
if (leftResult) set vars
if (rightResult) set vars

Then this exposes the fact that the variables can be set after the code is essentially finished.  Also, since the check is essentially complete if one of the results is true, there can be an inherent return before the setter, meaning that setting state can happen outside the function.

All in all, if you break this function into pieces, you should be able to get function names that are more concise / clear / no functions modifiying state inside a check function.