Fixing problem with numpys machine dependent definition of np.int
when trying to write integer data with audiolabs write_frames() method.

Problem: When trying to write integer data to a soundfile on a 64bit
machine the written data gets truncated in odd ways if it is stored in
an np.array of dtype np.int, because libsndfile expects 32bit integer data
but np.int is 64bit wide on that machine.
Storing the data as np.int32 doesn't help either, because np.int32 != np.int
on 64bit and audiolab refuses to accept it that way.

Fix: Explicitly adding np.int32 as accepted dtype for libsndfiles write_frames_int()
function allows to write int32 data. Additionally handling of np.int64 is done by
shifting the data 32 bits to the right and converting it to np.int32 on the fly.
This way it gets truncated in the way described in audiolabs and libsndfiles
documentation which says that truncation is done so that MSB always stays MSB.
As far as I have tried the dtype comparison of input data given as np.int yields
True for np.int32 or np.int64 depending on the actual width of np.int.
This is also true for the comparison of np.short with np.int16, so I changed that too.

Additionally: To regenerate _sndfile.c from _sndfile.pyx with cython 0.17.4 I had to
change "cimport stdlib" to "cimport libc.stdlib" and replace calls to stdlib.strlen()
with pythons builtin len() which according to http://wiki.cython.org/FAQ seems to be
the way to do that since cython 0.12.1