ImageContainer#cancelRequest is unsafe to call off the main thread

[jpd236]

As noted in #130, calling cancelRequest may mutate mBatchedResponses at the same time that it is being read in ImageLoader#batchResponse's inner Runnable, which is queued on a main thread handler.

Need to take a closer look at the thread safety guarantees here and either fix them or add documentation on constraints (e.g. only cancel requests on the main thread).

[jpd236]

ImageLoader (parent class of ImageContainer) has always had Javadoc noting that all calls must be made from the main thread. So I think it's reasonable to enforce this in 1.1.1, even though it may technically break some users, because doing so would have been a clear application bug.

This class is making an assumption though that response delivery happens on the main thread, which is generally true for any ResponseDelivery implementation (including the default), but isn't a guarantee. We could generalize this, but the class is special purpose enough (and tied directly to UI) that I'd rather we just document this limitation and otherwise assume UI thread execution.

The main risk here is that we also need to enforce that NetworkImageView#setImageUrl be called from the main thread. This is because it will initiate a load of the image (if necessary), which will cancel any invalidated in-flight requests. While this wasn't documented, I do think it's clearly the right thing to do, and I think it's worth the risk to enforce that this be called from the UI thread as well.