ENH: create Timedelta scalar / TimedeltaIndex

closes #3009
closes #8187
closes #8209
closes #4533 
closes #8190
 
This PR creates a new ``timedelta`` sub-class, the scalar ``Timedelta``, very similar to how ``Timestamp`` sub-classes ``datetime``. Further it creates a ``TimedeltaIndex`` modelled on ``DatetimeIndex`` that holds the underlying data (boxing is only on iteration).

- ToDo
  - Document API changes:
     - [x] ``to_timedelta`` return ``TimedeltaIndex`` rather than a ``Series``
     - [x] ``to_timedelta`` with scalar returns ``Timedelta`` (rather than ``np.timedelta64``)
     - [x] Boxing for ``list(Series(...))`` is now ``Timedelta``
     - [x] possible repr changes
     - [x] ``timedelta_range``
     - [x] usage / examples
     - [x] API
  - Timedelta
      - [x] conversions ``to_timedelta/to_pytimedelta``
  - TimedeltaIndex
      - [x] conversions ``to_pytimedelta``
  - [x] what else needs boxing in Series?
  - [x] fix formatters (Timedelta64Formatter; remove ``repr_timedelta64`` (no longer necessary)
  - [x] create ``timedelta_range`` & fix freq / inferred_freq
  - [x] fix remaining copied methods from DatetimeIndex
  - more tests (of TimedeltaIndex / scalar)
      - [x] scalar comparisons
      - [x] index comparisons
      - [x] getitem / partial string access
      - [x] sql expecting ``np.timedelta64`` ? (currently skipping these 2 tests!!!!), see: https://github.com/jreback/pandas/commit/2743ef16f7dfe55ba63663fa65c5671031af94f1
      - [x] validate series / td ops
  - move methods of ``TimedeltaIndex/DatetimeIndex``
      - [x] move ``DatetimeOpsMixin`` to ``tseries/base.py``?
      - [x] ``shift/take/order``
      - [x] ``slice_indexer``
      - [x] ``append/union/intersection``
      - [x] comparbless?
      - [x] ``.dt`` accessor are ok now
      - [x] move ``.td`` to ``.tdi``
And @jreback, to be clear, I also understand your point, and don't want to sound aggressive. But I just think that, from a user perspective, it is important to have a very clear user interface, and having a lot of undocumented/semi-internal functions is tab compl/api docs is not good for that IMHO. 
I rather think we should go more in that direction to convert some of these methods to private methods. Isn't there another way to eg define explicitely which functions appear in __dir__ ? (but that is also a lot of maintenance work of course)