Prevent concurrent contract revision

Also, downloaders are now thread-safe and cached by the contractor. They are referenced by their ID rather than the full contract object. This means less contract objects floating around and therefore less chance of saving/revising the wrong contract. It also opens the door for a future change: the contractor should be able to invalidate any active downloaders/editors as soon as it starts renewing their underlying contract. Generally speaking, the contractor should be the only package that deals with contracts directly.

One downside of caching, however, is that it complicates the question of when the connection should be closed. In this PR, I added a counter to the downloader object. Each time another goroutine starts using the downloader, the counter is incremented, and each time Close is called, the counter is decremented. Close only closes the underlying connection when the counter reaches zero.

Another complication is timeouts. The download RPC has a hard deadline, after which it will close. The existing download code essentially ignores this possibility, but the likelihood of hitting the deadline increases if connections are being cached and reused. To address this, the download code should attempt to reconnect when the deadline is reached. Ideally, it would detect timeout errors and only retry in that case, but it may work fine to simply retry after any failure.

My next step is to give downloads a way to interrupt uploads in the renter. I will use a simplistic approach because it appears the uploading process may shortly be subject to more dramatic changes.