ENH: ma.asarray() and ma.asanyarray() will pass through input of the correct type.

If x is of type MaskedArray for ma.asarray(x) or any subtype of
MaskedArray for ma.asanyarray(x), these functions will simply return x.
This makes them consistent with their numpy counterparts.

Closes gh-4043.
BUG: Fixed mask_rowcols().

Previous implementation relied on ma.asarray() to always create
a new object.

See gh-4043.
BUG: Error checks for the dtype shape.

Also creates a clean tuple for the shape tuple, instead of
passing potentially mutable objects through.

Closes gh-4009
ENH: Type specific binary search functions for `searchsorted`

This PR replaces the generic binary search functions used by `searchsorted`
with type specific ones for numeric types. This results in a speed-up of
calls to `searchsorted` which is highly dependent on the size of the
'haystack' and the 'needle', with typical values for large enough needles
in the 1.5x - 3.0x for direct searches (i.e. without a `sorter` argument)
and 1.2x - 2.0x for indirect searches. A summary benchmark on float and
int arrays can be found [here](https://gist.github.com/jaimefrio/8704101).

Furthermore, the type specific binary search functions can take strided
inputs for all their arguments, which is a step in the right direction to
eventually add an `axis` argument to `searchsorted`.
BUG: check for monotonic bin arrays in digitize

The check for monotonic bin arrays of digitize doesn't properly handle
inputs with repeated entries at the beginning of the array:

```
>>> np.__version__
'1.8.0'
>>> np.digitize([1], [0, 0 , 2])
array([2], dtype=int64)
>>> np.digitize([1], [2, 2, 0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: The bins must be monotonically increasing or decreasing
```

Modified `check_array_monotonic` in `_compiled_base.c` to skip over repeating
entries before deciding to check for increasing or decreasing monotonicity
and added relevant tests to `test_function_base.py`.
- Modified resetting of binary search indices when multiple keys are being
  searched, following @juliantaylor's suggestion. This speeds up searches of
  ordered keys by a lot (up to 3x), but slightly slows down purely random
  keys. Some benchmarks are available [here](https://gist.github.com/jaimefrio/8704101#file-gistfile2-txt)
- Added tests for proper handling of the smart index resetting when the last
  key was larger than all items in the searched array.
- Added basic tests for all implemented dtypes.
- This last change unearthed a funny behavior of `PyArray_CheckFromAny`,
  which was changing the byteorder attribute of `NPY_UBYTE` from `NPY_IGNORE`
  to `NPY_NATIVE`, and triggering lots of failures in `np.core.test()`. So I
  modified `PyArray_CheckFromAny` to leave `NPY_IGNORE` byteorders alone.
- Removed the now unused binary search functions from `item_selection.c`.
ENH: Attempt to rewrite the index parsing.

Some optimizations still missing.
WIP: Speed improvements by using EXTERNAL_LOOP
WIP,TST: Fix tests to match new behaviour
WIP: use fast_take and fix Deprecations
WIP,TST: Small fixes for the tests
WIP: bug fixes and field oder access change
WIP,TST: Fixup python3 tests
WIP: fix field order; And MapIterNext iteration end
WIP,TST,DOC: tiny fix

maybe triggers Travis too...
WIP: Move Ellipsis setting check and clear warnings
WIP: Restore binary compatibility of MapIterObject (hopefully)
WIP,ENH: Already allow boolean scalars for 0-d arrays

Since indexing into a 0-d array with an integer is impossible,
we can disable any conversion/interpretation is integer code
to special case the 0-d array for now and fix this annoying
issue...
WIP,BUG: Fix outer iteration bug.
Attempt to start optimizing setmap