CLN/INT: remove Index as a sub-class of NDArray

make ``Index`` now subclass ``PandasObject/IndexOpsMixin`` rather than ``ndarray``
should allow much easier new Index classes (e.g. #7640)

This doesn't change the public API at all, and provides compat (with exception of a very minor ``DatetimeIndex`` comparison with ndarrays)

closes #5080, preserves pickle compat for >= 0.8.0
back compat for pickles is now way simpler

This removed pickle compat for < 0.8.0 (well I think it does but can't really prove it). maybe can add it back if strong interest.

ToDo:

- docs
  - [x] release note
  - [x] warnings in io.rst about this change
  - [x] pickle compat now > 0.8.0
  - [x] fixes ``.repeat`` on MultiIndex (broken in master)
  - [x] minor API compat issue with comparisons of ``DatetimeIndex`` with ``NaT`` vs ndarrays
- [x] merge with searchsorted issues/PR ( #6712, #7447, #6469)
- [x] tests fixed (FIXMES), just a few left
- [x] perf
- [x] json completely broken ATM
- [x] #7796 FIXME (PeriodIndex not supported in HDF), not really a big deal
- [x] #7439 since ``Index`` now doesn't have implicit ops (aside from ``__sub__/__add__``, these need to be added in (e.g. ``__mul__,__div__,__truediv__``).
- [x] bool(Index/MultiIndex) : https://github.com/pydata/pandas/issues/7897 (will address this later)

closes #5155 (perf fix for Period creation), slight increase on the plotting
because of the the plottling routines holding array of Periods (rather than PeriodIndex).
```
-------------------------------------------------------------------------------
Test name                                    | head[ms] | base[ms] |  ratio   |
-------------------------------------------------------------------------------
period_setitem                               |  16.2210 | 122.9340 |   0.1319 |
timeseries_iter_periodindex                  | 1197.7839 | 6906.1464 |   0.1734 |
timeseries_iter_periodindex_preexit          |  12.4850 |  69.8563 |   0.1787 |
timeseries_period_downsample_mean            |  11.2850 |  11.1457 |   1.0125 |
plot_timeseries_period                       | 107.6056 |  86.5277 |   1.2436 |
```
Personally I am in favor to as much as possible document all index methods in the `Index` docstring in such a way that it is also applicable for the MultiIndex (so no different docstrings for the Index/MultiIndex). Of course there will be some exceptions where this is not possible (methods that are unique for `MultiIndex`), but I don't think this is the case for `repeat`. 

To avoid a profileration of methods in the API docs. This is in general a bit of a problem with our docs with increasing number of classes that share a lot of methods (Index, FloatIndex, DatetimeIndex, MultiIndex, in the future maybe CategoricalIndex and others ...)

But the unique methods of `MultiIndex` and `PeriodIndex` should indeed certainly be added.