The additional guarantee that Object.SymlinkHeaders becomes equivalent
to Object.Headers for non-symlinks will be useful e.g. for
swift-http-import's usecase.

It's trivially replicable by clients, and has an ugly API that I don't
want to commit on at this point.

I thought about this some more, and I believe the Writer-based approach
in the previous version of the LargeObject API does not scale: It makes
it very hard to write code that uploads segments without resorting to a
buffer the same size as the segments. I don't want gigabyte-scale
buffers filling up my RAM, so this commit switches to a different API
based on Readers. LargeObject.Append() now behaves very similar to
Object.Upload(), which I find quite nice.

This has gone through a lot of iterations on my branch, and I'm quite
happy with the parts of the API that exist now. Test coverage can still
be better, and will get better in the following commits.

The API is not yet finished: I want to add Options arguments to
Object.Upload(), Object.Copy(), Object.Move() and Object.Delete() that
specify how each of these operations affect existing segments (and,
later, also existing symlinks). For Upload(), uploading in segments
shall become as easy as flipping a single switch.