The native st_size-based approach to size estimation is broken because mutable
and immutable layouts have a different amount of overhead.  So start peeking
inside the share files.

Also, new_length must be respected now because when it is used the part of the
share file we peek at changes.  Also, new_length can *only* truncate so stop
treating it as if it can extend.

Do it another way.

Disregard `new_length` for pass calculations in `slot_testv_and_readv_and_writev`.

and without new_length

Instead of assuming all shares are the same size here, pass in all the sizes.
The protocol doesn't allow immutable shares in a storage index to have
differences in size but it does allow mutable shares in a slot to differ this
way.

Supply and enforce a correct ZKAP count for mutable writes

Deny writes to shares without an active lease.

Also make it use slot_testv_and_readv_and_writev instead of slot_readv

The behavior should be the same and slot_readv is simpler and less
interesting.

this seems likely to be wrong.
it's probably fine for slot creation but for later writes to a slot it will
probably underestimate the passes required.
we probably have to look at the "data length" of any existing share

Immutable shares are limited to what you can pay for with 10 passes right
now.  This certainly needs to be lifted but until it is we don't want spurious
test failures telling us about the limit.

Mutable shares are limited to what you can pay for with 1 pass right now
because the client doesn't know how to compute the right number of passes and
always spends 1 pass.

Integer division lets this number be zero sometimes.

Some docs and cleanups which are additional to those from #42 

This should have been part of the earlier merge but in the process of self-review I forgot to push all of my changes before using the GitHub merge button.

Server-side cryptographically correct pass checking for allocate_buckets