The _closest() method already defined a way to do what _matches() was
trying to accomplish.  This pulls the functionality out of _closest() so
that it can be reused outside of _closest() but refactors _closest() to
use this new _matches() method.

For instance, say you are sorting tbody's within a table element.  There
can also exist tfoot and thead within the table element.  The _index()
function assumes that the list of elements within the parent is
homogenus (ie: just li's below an ol/ul).  This isnt the case when
sorting tbody under table.  This is edge case until you want to group
tr's under a table and sort on those groupings.

don't trigger start event when an element is been dragged, otherwise the evt.oldindex always wrong when set option.group.

should fix #618 and #597

oldIndex was changed first by with the item being dragged, but also by the drag event of the parent (which should be avoided when we are not using the drag-handle)

This event will fire when an element is chosen, and is particularly
useful for providing the user with a visual, auditory or tactile indication,
in case a delay was enabled.

An attempt to implement the "distance" option (like http://api.jqueryui.com/sortable/#option-distance).
This is useful when your sortable element is also clickable. This prevents the drag to begin due to a micro-movement when you click.

And so on: #558, #547, #542, #537, #532, #516, #500, #489, #489, #447, #475, #459, ##422, #411, #356

when nesting Sortable's, we're not interested in this error:
"HierarchyRequestError: Failed to execute 'appendChild' on 'Node': The new child element contains the parent."

As done in the other place where `dataTransfer` is used.
This is to support fake html5 drag and drop events, where `dataTransfer` is not accessible. Use case: Selenium testing with ePages-de/chromedriver-html5-dragdrop

#356 Fixing issue where dropping an item on the right end of a horizontally layed out drop zone does not add the item