feat($concurrent-chunks): Track upload batches #937

Also apply the same changes to the existing concept of proxy groups.
feat($concurrent-chunks): cleanup qq.UploadData.addFile #937

Too many parameters.
chore($handler-cleanup): start of endpoint handler refactor #1157

This commit covers simple file uploads for traditional endpoints.
chore(test/fineuploader/UploadReceiver.java): don't consider part idx when determining if done #937
test(test/fineuploader/UploadReceiver.java): don't track canceled parts #937
chore($handler-cleanup): chunking working for traditional endpoints #1157
chore($handler-cleanup): more progress moving chunking logic out of specific handler impls #1157
chore($handler-cleanup): rename handler files/classes to better describe roles #1157
Merge branch 'develop' into feature/concurrent-chunk-uploads
chore($handler-cleanup): rename handler files/classes to better describe roles #1157
chore($handler-cleanup): centralized progress calculation for handlers #1157 #584

Previously, for chunked MPE uploads, we would report the progress of the entire request for each chunk.  Since there is no way (that I know of) to accurately calculate the exact size of a MPE request before it is sent, we maintained an estimate of the size of the non-file portion of each MPE upload chunk request and used that to determine how many exact bytes were left to send over all remaining chunked requests per file.  I've changed this approach.  Now, we only report the progress in terms of the size of the actual file we are uploading.  We simply assume that the total number of file bytes uploaded for a specific chunk at a given time, given a progress event from the browser, is equal to the number of bytes sent for that request minus the difference between the size of the request according to the progress event and the actual size of the file's chunk.   The benefits to doing this include better likelyhood that we will reach 100% (and show the processing status) in browsers such as Firefox when the last progress event has been received from the browser.  Also, this means that the total parameter of the onProgress callbacks remain constant (this could change over the course of a chunked upload as we re-estimated the total size of all requests).
chore($resume-localStorage): finish switch from cookies to localStorage #1157 #1024

- resume.recordsExpireIn now used for all endpoint types - no more cookiesExpireIn
- Removed all cookie-related functions in util.js
- Resume capability detection looks at existence of localStorage instead of if cookies are enabled/disabled
chore($handle-cleanup): start to remove as much of resume concept from specific endpoint handlers #1157
chore($handle-cleanup): move resume-specific logic out of endpoint handlers (traditional) #1157
chore($handle-cleanup): specific endpoint handlers should be more focused (traditional) #1157
chore($handle-cleanup): specific endpoint handlers should be more focused (traditional-form) #1157
chore($package.json): Explicitly declare karma version
test(unit/scaling.js): more verbose failure messages
chore($handler-cleanup): reorganize handler controller #1157
Merge branch 'develop' into feature/concurrent-chunk-uploads