conflict fixed
transplanting missing classes from cling for android support
stashed changes
merge and library cleanup
needs servlets 3.0, not 2.5. Added jetty-util
cling update and transplant in place. hat-tip to @christianbauer from FrostWire Team.
Added a custom capped default executor for cling, verified with the debugger that it's indeed being used.
recompiled cling-kernel.jar under java 6
removed about.html from jars, android compiler was complaining about repeated files, added jetty-io library, required during runtime according to cling author
No more Runtime exceptions due to missing dependencies.
no runtime error from clins's UDN.uniqueSystemIdentifier method
Fixes reported NPE (reported at TransferManager.clearComplete line 170)
Fixes Runtime/NPE error with image cache - java.lang.RuntimeException: Unable to start activity ComponentInfo{com.frostwire.android/com.frostwire.android.gui.activities.MediaPlayerActivity}
[SILENCED but a more elegant and better performing implementation has been added and it's ready to be plugged after review]

java.lang.IllegalStateException: not connected to MediaScannerService
at android.media.MediaScannerConnection.scanFile(MediaScannerConnection.java:164)
at com.frostwire.android.gui.UniversalScanner$AndroidScanner.onMediaScannerConnected(UniversalScanner.java:145)
at android.media.MediaScannerConnection.onServiceConnected(MediaScannerConnection.java:249)

Q: Is it wise to use a single media scanner object/connection and disconnection per file?

   Looking at the implementation of scan, we are not reusing the MediaScanner connection,
   we're connecting and disconnecting for each file, this is probably causing issues when
   downloads are finished, issues which I've witnessed, torrents that finish and the files are never
   there, perhaps thanks to this IllegalStateException.

   I propose a refactor of Librarian.scan(File file, Set<File> ignorableFiles).

   I believe the algorithm should first perform a walk of the directory until it's maximum depth and
   put all files on a list. Then pass this list to the AndroidScanner, and scan them all using the same
   connection, also avoiding the use of stack memory with each recursive call to scan.

   I've implemented such algorithm with a new utility method on FilenameUtils.getFolderFiles() which walks
   a directory non-recursively (saving stack and 20% faster than the recursive older version).

   I've also refactored UniversalScanner, I've renamed the older "AndroidScanner" to "SingleFileAndroidScanner" and I've created a new one called "MultiFileAndroidScanner"
   This one takes the flattened collection of files and scans each one with the same MediaScannerConnection
   object. I understand that each time the scanner finishes scanning a file it invokes a method of its
   MediaScannerConnectionClient called "onScanCompleted()", in the old implementation this method would disconnect, now what I do is I keep count of how many files have finished scanning, once all files
   have finished scanning I then trigger the disconnection. I think there's a risk in case of error on which onScanCompleted is not called and the disconnection from the MediaScanner never happens.
   If connection.scanFile() is not asynchronous, then it's easy because we can disconnect when we're done,
   but judging for the older code, you disconnected only after receiving the callback.

   please review.
bullet proofing
plug new scan function, still gotta fix ignorable files logic
quick fix for library scanner
silence rejected execution exception
adding missing jetty dependency (http client)
Adding the right StreamClient implementations for Android