Add unsigned variants

[jamadden]

Fixes #120

I went ahead and just added unsigned versions of all the datastructures because…why not, it was easier that way (CLI scripting FTW).

This wasn't hard, just tedious, and there's an unfortunate amount of copy-n-paste at the Python level, so I may have missed something. (It would be nice to be able to reduce that, especially because I'd like to see about adding some more memory-efficient types, too, such as byte strings (char*))

I know some updated documentation is still owed.

One thing that is a bit weird, and deserves documentation at least, is the handling of the "weight" arguments to the intersection functions. You are allowed to pass negative values to unsigned datastructures, but the results you get will be meaningless. Python doesn't have a standard way to handle over/underflow in arguments. I figured those are lightly used and unlikely to be much of a problem, but I'm sure we could figure out a solution if necessary.

This has nothing to do with this PR, I just happened to notice it. Another thing that's a bit weird is that we talk about "family32" and "family64" expecting them to be 32- and 64-bit datatypes, respectively, but then the C code goes and uses standard C int and long long, which is not technically the same thing. The Python implementation isn't really any better, relying on the native sizes of the struct module. But we have specific tests at the limits of 32- and 64-bit types, so we rely on those sizes matching up. We'd be broken on a platform where they didn't.

[freddrake]

I'll try to take a look over the weekend.

[jamadden]

Looking at the coverage numbers, I see files like test_LLBTree.py (that wasn't changed here) have low coverage numbers. This looks to be because of issues with the test_suite functions methods repeating or skipping test names.

I'd like to see about removing those functions.

[jamadden]

I think that's all I want to do in this PR. It's big enough as it is :) I'd still like to address the duplication that made this tedious, but that's a followup PR.

[icemac]

Anyone who has the steam and knowledge to review this PR?

[jamadden]

I would appreciate any reviews and help getting this (and #123) merged.

[mgedmin]

big diff is big :(

[jamadden]

I've rebased and reworked to reduce the diff as much as possible. There's still a lot of boilerplate files, though (hence #123 :) )

Unfortunately, today's release of persistent is triggering what looks like a virtualenv bug under PyPy: The headers aren't getting installed to the correct virtualenv place; instead they try to go to the system header directory, which isn't writable.

[freddrake]

I'm afraid my weekends have been too busy lately, and that'll continue for another month. Will try to squeeze it in anyway... but we'll see.

[jamadden]

Are there any objections if I go ahead and merge and release these to get them out there?