obspy.taup now uses f2py instead of ctypes

Furthermore updated the setup.py script to use numpy.distutils. This
appears to get rid of all the old hacks and tricks in the old version.
Arch specific name for obspy.taup binary lib.

The obspy.taup library file created with the help of f2py now also has a
architecture specific filename. This unfortunately introduced a small
hack in the setup.py.
Also the architecture specific library names now use underscores instead
of dashes. This was done to avoid an issue with the f2py interface
files.
Small change to .gitignore
Fixing obspy.signal compilation.

Now compiles with the correct files...
Removing obsolete print statement.
Removing dependency on setuptools and distribute.
More robust path handling.
Small refactoring.
Import setuptools if available in setup.py.

This monkeypatches some functionality so commands like "python setup.py
develop" now should work again. See #431.
Not compiling fftpack_litemodule.c

This file is not imported anywhere and would need to be compiled in a
different manner as it is a Python extension.
Workaround for awkward MinGW bug

This appears to be a bug within MinGW and I hope this workaround is
stable enough. If it is, we should submit a patch for libmseed but it
still needs some more testing.
Simply using _fstat() returns -1 and does not fill the `errno` variable
so it essentially just quietly fails without raising at compile or link
time. I found some more references to issues with fstat() in MinGW on
the internet so the problem is more wide-spread.

I am using gcc 4.6.2 from MinGW 3.2.0 on Windows XP.
Fixing line-endings issue in obspy.sh
Merge branch 'master' into f2py

Conflicts:
	setup.py
Manually add files specified in MANIFEST.in

Apparently numpy.distutils does not parse the file... Maybe there is an
other way to tell it to read the file.
- support for building C extensions using MSVC
Merge pull request #2 from barsch/f2py

- support for building C extensions using MSVC
add support for SEG2 data format code 2
Adding support for SEG2 data format code 1.

If data format code 2 is working as tested with a received data file
then I am confident that code 1 works as well. Both are just two's
complement integers with unspecified endianness - native byte order is
assumed.
Only data format code 3 is not supported now. It is an interesting
20-bit floating point format so we would definitely need a test file for
it.
adding test data and very basic read test for SEG2 data format code 2, thanks to Simon Kremers for the data example!
update CHANGELOG