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``
Ah, yes, I get your point of "inter-series-index-api" or "inter-module-api". That also makes sense. 
In such cases I think we should just carefully think if there is not another way, and if not, in many cases this can also be useful to (advanced) users in some cases and we should just document it properly (I mean give a proper docstring).

Eg in this case, I think `to_embed` is (for now) only used in `to_series`? Another option would be to override `to_series` in `DatetimeIndex` and `PeriodIndex` where we don't want to just pass through the ``values`` (and for `DatetimeIndex` this is actually already the case to provide the extra keyword `keep_tz`)

The main think I did not like here was the name `to_embed`, as we have a nice list of very nive `to_..` functions, and this would not really fit in the row .. :-)