Makefile: fix test and pydablooms static linking, simplify stuff

problem: since merging in support for building dynamic library,
test and test_pydablooms could fail if dynamic library was already
built but not already installed (because they were no longer linking
against the static library, but not finding the dynamic library at
test time)

premise: tests should be able to run without installing

premise: pydablooms should link to dablooms in the BLDDIR statically
so that it needs no version distinct from the libdablooms version

problem: pydablooms setup.py doesn't honor SRCDIR abstraction when
finding version number from dablooms.c (just for setup.py --version
which doesn't affect anything, but correctness is cool)

solution: remove SRCDIR and PY_SRCDIR abstraction, remove LIBPATH
and INCPATH variables, pass only BLDDIR to setup.py so it can
construct a specific path to libdablooms.a, link with libdablooms.a
explicitly

I could have specified LD_LIBRARY_PATH for tests, but I wanted to
simplify.

SRCDIR isn't very useful because all builds will be done with
CWD = dablooms project root dir. BLDDIR is the way build-time
objects are directed elsewhere (vs autotools projects for which
one can theoretically run the configure script from a different
dir, and get a Makefile there which will put all objects there)

the removal of INCPATH and LIBPATH are harder to defend; my argument
is that they are not currently needed by any actual users that I know
of, and they could be done a bit better (in a way that still works
when custom CFLAGS are also set)
Makefile: clean all library files specifically instead of globbing

plus we can save chars by re-using LIB_FILES
Merge pull request #37 from ploxiln/more_makefile_fixes

More makefile fixes
use ftruncate() to resize blooms file

instead of using lseek() repeatedly in a loop

(original commit by Vicent Marti, rebased and tweaked by Pierce Lopez,
any bugs added probably due to the latter)
replace MD5 hash with Murmur hash and improve salt generation

new hash function should be much faster now
salts should be better distributed now
clean up type of bloom->hashes and hash_func()

(original commit by Vicent Marti, rebased and modified to use the
128-bit hash for salt generation by Pierce Lopez, any bugs added
probably due to the latter)
use binary keys and lengths instead of NULL-terminated keys

more flexible and safe

Also, note that Python strings (and pretty much any dynamic language)
already keep length information. This will save us quite a few
`strlen` calls.

(original commit by Vicent Marti, rebased by Pierce Lopez, any bugs
added probably due to the latter)
round up bloom->hashes allocation to multiple of 4

this way hash_func() can always do 4 hashes at a time
simpler loop logic is a tiny bit faster

also clean up num_salts handling a bit

(original work by Vicent Marti, rebased and pulled out by
Pierce Lopez, any bugs are probably due to the latter)
Merge pull request #39 from ploxiln/vmg_perf_branch

Vmg perf branch
new_scaling_bloom() does not need an id, 0 always works

The id argument is the starting id of the first counting bloom in
the scaling bloom. It might as well be the lowest possible id,
because for an item with a "very low" id, the user definitely wants
to put it at least in the first counting bloom anyway, instead of
rejecting it.

The starting id of the next counting bloom is set to the highest id
of any item when the first counting bloom fills, and thus is not
really affected by the initial id.
Merge pull request #24 from ploxiln/scaling_no_id_24

new_scaling_bloom() does not need "id" argument
go library
switch to using []byte (no additional allocations)