types,consensus: Add Capacity field to V2FileContract

[lukechampine]

This field clarifies some long-standing confusion around the economics of file contracts.

When you pay for storage in a file contract, you are buying that storage for the remainder of the contract duration. This means that, even if you delete some data, you do not get a refund. Why not? Well, mainly, how do you price the refund? If you use the host's current prices, the host can manipulate them in order to minimize the refund. On the other hand, if you use the original price, now you have to keep track of what the original price was -- and not just the price, but also how long each sector was originally stored for. That's a lot metadata, and both the renter and host need to track it accurately, or they'll disagree on the price and stop communicating entirely.

Okay, so we can't do refunds. But we also want a way for renters to get rid of data they don't care about. One way to do that is to overwrite the garbage data with data we do care about. For this to work, though, the renter has to keep track of the garbage sectors, which is annoying. In general, we want to minimize renter-side state (to facilitate light clients), so we shift responsibilities to the host and use cryptography to make sure the host doesn't cheat. So in RHPv4, that's the plan: have the host keep track of the garbage sectors, so that when you upload new data, the host can reuse existing capacity instead of increasing the contract size. This is why we need a capacity field: to ensure that the host doesn't lie about how much capacity is available.

Fixes #217

[lukechampine]

hmm... how do storage proofs interact with this, though? Shouldn't we use the capacity, not the filesize, to choose the proof index? But if so, the storage proof could be for an empty sector. Maybe that's okay? Feels a bit weird though.