Handle StopResponse correctly in proto

As reported in #1346 (closed), the renter protocol was not properly handling StopResponse during revision. The correct behavior is to apply the revision and then gracefully terminate. Instead, the renter treated StopResponse as an error and exited early without applying the revision. This caused the renter and host to desync.

Note that in this implementation, the renter will not know that the host has closed the connection until it tries to perform another revision operation. An alternative approach would bubble the ErrStopResponse error all the way up to Upload, Delete, etc., and the caller would have to check for this error specifically and handle it correctly -- namely, they would have to recognize that the other return values were still valid, despite err != nil. I opted not to take this approach, because there is little benefit and the renter needs to be safeguarded against random host disconnects anyway.

On that note, this PR should also fix a subtle bug affecting cached revisions. Previously, SaveFn was called before doing any network I/O. This meant that if the host had silently disconnected, the renter would cache the revision before finding out. By itself, this shouldn't cause the renter to desync (since it will first try the current revision, not the cached revision), but it may have compounded other issues.