Use delegated call, do not call it directly

As the handler has means to break endless
loops by inspecting is path requires managed
attributes or not.
Add filters to DirSupport class.

To be able to filter out some directories from recursive
copy/move/delete operations.

This is basically the culprit of the bug with trash, when
endless recursion caused long OS paths and resulted in
FileSystemEx, when repo root deletion is attempted.
Make DefaultFSPeer use new DirSupport method with proper filter

As in case of move/delete, it would not only delete the
repo content, but also repo "metadolders" like ".meta"
(less of a problem), and ".nexus" where trash is, basically
performing a "move into a subdir" of directory. This ended
up in endless cycle, broken when OS refused file creation
for too long pathnames.
IT related fixes and improvements.

Changes:
* unset auto-block, that caused this IT to block indefinitely and be killed by failsafe (without giving any clue what happened to it)
* Removal of redundant class, as Get exists in HTH library.
* Setting log levels to DEBUG of affected components,
* Removal of "circumvention" for root repo deletion inability
Do not use Files.move when filter in effect and filter rename

As Stuart suggested. Also, the Files.move should not be even
attempted if filter is given, and use the fallback immediately
Merge pull request #761 from sonatype/nexus-2.11.x-routing-fixes

Nexus 2.11.x routing fixes