Content size

This patch addresses the following bullet

* http/ftp/etc. content size limit
In the fetchers we currently do a ReadAll to the response body, but for large responses this is inefficient. We should preallocate a buffer big enough for the claimed response size. We also would like a config parameter to limit the response sizes we'll accept; any response over the max size should act like a failed fetch and indicate in the fetch error that the response was too large for us. One tricky thing is that if the response does not specify a size (content-length), we won't know until we've started reading that the response is too long. This is especially a problem if we try to pass the response to HandleResponse without pre-reading the data; to handle that we would probably have to wrap the reader and make it cut short if the response is too long. For the time being it should be acceptable simply to read the response in every time, like we currently do for HTML pages.
This has come up before, would like to discuss just for a second. The thing about sscanf is that ANY numeric conversion a programer needs to make can go through this api. Including, as I use in this example, a 64 bit integer (though in this example the 64 bit-ed-ness isn't __that__ important). Atoi only gives you standard int, no off-sized ints, and no floating point. The sscanf interface is slightly more complicated than atoi, but once you learn it -- you have any numeric conversion you need. More generally sprintf/sscanf together reproduce all the functionality (or much of it) that the strconv package implements with more than a dozen methods. I would argue that using sscanf simplifies the code base as a whole, even though it may be more complicated than the corresponding single conversion routine in strconv.