Allow arbitrary TorrentByteStorage implementations

[shevek]

The library has a TorrentByteStorage interface, but I cannot specify a custom TorrentByteStorage in SharedTorrent (e.g. if I want to write my torrent data to something which is not a file).

SharedTorrent stores it as a private field, and other classes reference SharedTorrent by implementation, not interface, so I can't use the library as-is for my purpose.

I'm hoping to shift >100Gb of data to >100 clients, so I can't really afford temporary filesystem space.

[shevek]

Trying to patch this, it makes me wish that SharedTorrent (which is a runtime state object) embedded/wrapped Torrent (which is an almost-immutable model object), rather than extending it. The same is kind-of true of TrackedTorrent, but I don't care about that because I'm not in there.

[shevek]

Reason being, by the time we have enough information about the torrent files and size, and so on, we're stuck in a constructor. This means that we can't pass a pointer to the parsed Torrent object to any routine which constructs a Storage object from it, as we really want to be within a 'this()' call. Being in a subclass constructor sucks.

[shevek]

Merge this with issue 77 and PR77 please.