Added SDWebImageOption to enable Cookies Handling.
Merge pull request #553 from danpe/master

Added SDWebImageOption to enable Cookies Handling.
Allow setting a custom memory cost limit for the in-memory NSCache. This can help to keep memory down before memory warnings are sent by the device.
NSInteger -> NSUInteger, add getter method
Merge pull request #556 from JoshuaGross/master

Allow setting a custom memory cost limit for the in-memory NSCache.
up version 3.5 in podspec to be consistent with latest
Merge pull request #558 from shifu/master

up version 3.5 in podspec to be consistent with latest
Add HTTP header filter to pick headers for downloading request
Merge pull request #514 from crazytonyli/header-picking

Add HTTP header passing test to pick header for downloading request
added currentDownload Count, to allow someone to see how many operations are left.
matched coding conventions
Merge pull request #562 from mknippen/master

added currentDownload Count, to allow someone to see how many operations are left.
Bump version to 3.5.1 (fix #568)
Added a delegate for the web image prefetched.
Code cleanup.
Merge pull request #577 from pieterclaerhout/master

Added a delegate for the web image prefetched.
Using webkit's method for determing frame durations of various gif images
Updating podspec
bleh
Fix race condition in image download cancellation

There are many race conditions around cancelling
SDWebImageDownloaderOperation instances from other threads. For example,
imageData may be set to nil and deallocated just as it is being appended
to, or the threading can interleave in such a way that messages are sent
to a deallocated connection. These were discovered using SDWebImage for
a Google Maps-style tiled mapping application where there is a lot of
download and cancellation if users pan rapidly.

This fix tracks the worker thread that the NSURLConnection instance runs on and
performs cancellation on the worker thread. The cancel and start methods need
to be synchronized to handle the case where cancellation happens before
start is called; since no thread has been assigned yet, cancellation is
performed on the calling thread.

Because cancellation is now scheduled on the same run loop as
NSURLConnectionDelegate callbacks, there is an added window of time that
a download can finish prior to cancellation. This means it's possible to
cancel an operation yet still get a successful completion callback. This
was always possible because of race conditions, but it is more
pronounced and predictable now. An application that relies on
a cancelled operation never calling its completion block (e.g. recycling
image views in a scrolling table view) must adopt some other mechanism
(e.g. a version number) to avoid running completion code for a stale operation.