Add a mark stack to BitstreamWriter objects.

Seekable streams (pure file objects or Python objects with .seek()
and .tell() methods) can have marks so long as the positions being
seeked to *and* from are byte-aligned - usually for rewriting the
start of a file or a seektable, etc.
Merge branch 'master' of /home/brian/audiotools.bundle
Catch more write errors and raise exceptions in bitstream module.

These are pretty rare when writing to actual files, but may
occur more often when calling Python methods.
Add seperate mark stacks to BitstreamReader and BitstreamWriter.

That is, the same stream can have multiple stacks of marks
with their own integer IDs (meant for use with an enum)
which can be rewound to seperately.
Fix simple PCMReaderProgress bug.
Convert several standalone bitstream functions to methods.

Integrate the new BitstreamWriter mark() interface in the encoders.

WavPack benefits from this in particular because block headers
can be written first and have their size values filled-in later
rather than having to dump all the sub block data to a second recorder.
Shift the callback handlers to methods.

This removes some of the last standalone functions in the bitstream module.
Remove limited_unary method from BitstreamReader

Replace the only instance of its use (ALAC decoding) with Huffman tree
decoding, which is easier to follow anyway.
Simplify the BitstreamReader Huffman type values

The multidimensional struct layout is the same as before,
but typedefs make it much easier to sort out.
Update Huffman code writer for consistency with reader

This is mostly hypothetical since the writer isn't used anywhere yet.
Implement proper seeking for function-based BitstreamReaders

Analagous to how it works with BitstreamWriters, some object
is pushed onto the mark stack to be cleared out later.
The main difference is that the reader's buffer contents
are also pushed along with the mark to be restored later.
Import reduce from functools if necessary

It's one of the more bizarre Python 3 reorgs.
"map" sticks around even though list comprehensions do the same job,
but "reduce" gets banished to the functools module.

Seems like doing it the other way around would make more sense.
Cleanup a few minor Python 3 related items.
Bump version to 2.22 beta 2

Should be the last beta version before 2.22 final.