URIs could be a bit smaller

[warner]

The URI currently contains separate readkey and StorageIndex fields. We should redefine the read-cap CHK file URI to include just the readkey and derive the StorageIndex from it by hashing.

[warner]

We've addressed the most immediate problem here, by moving many of the pieces off to the URIExtension, and including the hash of that datablock in the URI itself. This makes the URIs smaller, at the expense of increasing the storage overhead slightly (about 200 bytes per share), and increasing the alacrity slightly (you have to pull 200 bytes from one shareholder before you can verify the first segment).

Once we also switch to deriving the StorageIndex from the readkey, this will shrink the URI down to the following pieces:

• readkey (base32-encoded 16 or 32 byte value)
• URIExtension hash (base32-encoded 32 byte value)
• needed_shares/total_shares (two small integers, normally "25" and "100")
• filesize (3-7 bytes, really just for quicker UI purposes)

(at the moment, we track the readkey and the storage index separately, so our URIs are another 53 characters longer than this)

I'm redefining this ticket to be about reducing the size of the URI, by deriving the StorageIndex from the readkey. The issue of algorithmically generating things like segment size and encoding parameters from the filesize is less important, in my opinion, now that it's been pushed out to the URIExtension.