Investigate supporting Tahoe-LAFS mutable capabilities

[crwood]

The keys which constitute Tahoe-LAFS mutable capabilities are derived from RSA keys (passed through a custom "tagged" sha256d hash function as per hashutil.py). Investigate how/whether this library could or should support generating equivalent Tahoe-LAFS capabilities without the need to depend on Tahoe-LAFS itself.

[crwood]

Some other reasons to do this:

• The allmydata package isn't really designed or intended to be used as a python library/API.
• Deriving a Tahoe-LAFS capability string currently requires making an mkdir call to the Tahoe-LAFS web API -- which, in turn, requires being connected to a live grid; it would be useful to be able to reconstruct caps "offline" as a pure function, etc.
• Attempting to re-create a Tahoe-LAFS directory that already exists (i.e., by supplying the same RSA key to the mkdir call) throws an UncoordinatedWriteError and may lead to data-loss.
• Another implementation (and common test vectors?) helps verify existing functionality.

[crwood]

The recently-published "lafs" crate provides a working Rust implementation of the 'allmydata.util.*' functions necessary to derive Tahoe-LAFS mutable capabilities/URIs completely "offline" (i.e., without depending on a running python Tahoe-LAFS node). Integrating such functionality directly into this crate, however, is presently blocked on https://github.com/crwood/lafs/issues/12

In the interim, Python applications wishing to derive a Tahoe-LAFS mutable URI from a BIP-39 phrase can still do so by interfacing with each library separately -- i.e., by using deterministic_keygen to derive an RSA key and then calling lafs.derive_mutable_capability with that key to derive the final URI.