Provide viewState/grabOffset in event data? about react-native-drax

[lafiosca]

Let's add the relevant values from that object to each of the dragged and receiver items in the drag events, as required rather than optional, for accuracy/convenience.

The dragged item will now have:

	/** If being dragged or released, the relative offset of the drag point from the view */
	dragOffset: Animated.ValueXY;

	/** If being dragged, the relative offset of where the view was grabbed */
	grabOffset: Position;
	/** If being dragged, the relative offset/dimensions ratio of where the view was grabbed */
	grabOffsetRatio: Position;

	/** The position in screen coordinates of the dragged hover view (dragScreenPosition - grabOffset) */
	hoverPosition: Animated.ValueXY;

Note that we omit dragScreenPosition because it's already in the event data. Also I am uncertain on hoverPosition, although I don't think it hurts to include it, and even if noHover is enabled the value still exists unused.

We've already added the relevant values to the receiver data in #15

[lafiosca]

I forgot that we can't access the viewState directly in the provider handler methods because we'll end up in a circular dependency. These methods only operate on the registry ref values and update state via dispatch, never depending on reading state. Still, the registry is able to calculate the updated values to dispatch to the updater, so it must be possible to have this information. It just might be awkward with the current logic organization.

[lafiosca]

But I completely misremembered where this data lives. Yes, it's reflected in the viewState, but some or all of it is also in the registry and accessible (perhaps with some extra convenience methods).

[lafiosca]

This is definitely a breaking change, as some field names will be changed for consistency as well.

[lafiosca]

Why are we using Animated.ValueXY for these in the first place? It's harder to access the x/y values from those. We should only be using Animated values when we need to animate them. Currently the only one the library is animating is hoverPosition, which makes sense. (DraxList also uses its own animated shifts internally, but those don't matter for this.)

[lafiosca]

Forgot to close this issue when it was addressed by PR #18 and released in 0.5.0