BUG: Fix regression for in1d with non-array input

There was a regression introduced by the speed improvement in
commit 6441c2a. This fixes it, and generally ravels the arrays for
np.in1d. However it can be argued that at least the first array should
not be ravelled in the future.

Fixes "Issue gh-2755"
TST: Add test for in1d ravelling

The behavior of in1d is not really defined here, but it should
be at least consistent over different execution branches. This is
what it has been for most usages.
TST: Add tests for constants.

Test the values of np.pi, np.e, and np.euler_gamma to make sure
they are correct to relative tolerance 1e-15.
TST: Replace Python 3.1 test with 3.3.

Travis does not support 3.1 anymore, but supports 3.3. See:

https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion
ENH - .mailmap file to harmonize git shortlog

Reduce duplicates in git shortlog
Fix invalid typestring size

Revert to pre numpy 1.7 behavior where invalid typestring size was ignored and isplay deprecate warning. This warning should eventually be changed to an error in future numpy versions.
Refactor to cover more cases; modify unit tests
Modify unit tests for 32 bit support
Refactor unit tests and add DECREF

- Refactor unit tests for invalid dtypes so that each test is on a separate line. This will make it easier to figure out which typestring is failing the unit test.
- Add Py_DECREF for temp variable
Add debug logging to figure out why unit test fails on Travis
Add fix to unit test; remove debug logging

Add check to see if 12 bytes is a valid size for a long double
FIX: Use the NPY_TIME_T macro everywhere

Previously, two (critical) parts of the code used `time_t` instead of
`NPY_TIME_T`. Due to the fact, that most of the time `NPY_TIME_T` was equal to
`time_t`, this bug didn't show up. But in mingw, `NPY_TIME_T` is actually equal
to `__time64_t` and then this causes 64 bit integers to be cast into 32 bit
integers (thus becoming negative), which causes localtime() to fail in mingw.

Fixes gh-568.
DOC: Thoroughly document datetime issues

After understanding the issues with datetime (see gh-568), I have documented my
understanding as comments in the code, so that the next time there are problems
with datetime on some platform, one can quickly figure out what is going on
from the code + comments.
DOC: document the change in .base

Forwardport gh-2737.
DOC: Add a blank line to multiline comments

Multiline comments should begin with a blank line. This patch fixes it.
FIX: remove a spurious check in get_cast_transfer_function

At least, I hope it's spurious. Certainly it's creating a spurious
error message, is unexpected by callers (one of whom specifically
makes the *opposite* check before calling get_cast_transfer_function),
and even if it is a useful check for some reason I can't see, it
certainly doesn't belong in this function (which is otherwise just
taking care of byte-swapping and alignment issues and doesn't know
anything about dtypes). And worst case, we'll have turned an exception
into a crash; even if I'm wrong, this shouldn't cause any code to go
from working to not working, just from broken to slightly-more-broken.

Test and original diagnosis by @cgohlke.

Fixes gh-2798.
BLD: Add support for Python 3.3 in paver
move to www.numpy.org
fix array interface documentation links
DOC: Add missing minus sign

The int64 data type allows numbers from -9223372036854775808 to
9223372036854775807. The minus sign was missing.