Introduction of RangeIndex
closes #939

`RangeIndex(1, 10, 2)` is a memory saving alternative to `Index(np.arange(1, 10,2))`: c.f. #939.

This re-implementation is compatible with the current `Index()` api and is a drop-in replacement for `Int64Index()`. It automatically converts to Int64Index() when required by operations.

At present only for a minimum number of operations the type is conserved (e.g. slicing, inner-, left- and right-joins). Most other operations trigger creation of an equivalent Int64Index (or at least an equivalent numpy array) and fall back to its implementation.

This PR also extends the functionality of the `Index()` constructor to allow creation of `RangeIndex()` with

```
Index(20)
Index(2, 20)
Index(0, 20, 2)
```

in analogy to

```
range(20)
range(2, 20)
range(0, 20, 2)
```

---

TODO:
- [x] Cache a private `Int64Index` object the first time it or its values are required.
- [x] Restore `Index(5)` as error. Restore its test. Allow `Index(0, 5)` and `Index(0, 5, 1)`.
- [x] Make `RangeIndex` immutable. See `start`, `stop`, `step` properties.
- [x] In `test_constructor()`: check class, attributes (possibly including dtype).
- [x] In `test_copy()`: check that copy is not identical (but equal) to the existing.
- [ ] In `test_join_non_unique()`: test .append for ri.append(int64index) and int64index.append(ri).
- [x] In `test_duplicates()`: Assert `is_unique` and `has_duplicates` return correct values.
- [ ] After consensus on desired behaviour, adjust `test_view()`.
- [ ] After consensus on constructor, adjust `test_constructor()` and possible add further tests.
- [x] After consensus on `RangeIndex()` validity, adjust `test_pickle_compat_construction()`.
- [ ] After consensus on slice behaviour, test for correct return type in `test_slice_specialised()`.
- [ ] Accept `xrange` objects as input
- [x] Setting `RangeIndex` as the default index.
- [ ] Clean up `Index` constructor: use ABCs and named arguments
- [ ] In `__getitem__()`: replace `np.isscalar` to exclude singe-element numpy arrays
- [ ] Tests for `pandas.io.packers`

In need of consensus:
- [x] If we disallow `Index(10)` should we also disallow `RangeIndex(10)`? That would seem like an unfortunate api break with respect to built-in `range()`,  `xrange()` and numpy `arange()`. _Decision: allow_
- [x] Should `RangeIndex()` be allowed as a constructor alternative to the kludgy `Index(np.empty(0, dtype='...'))`? _Decision: allow_
- [x] Should `RangeIndex` accept array inputs? If so, what should it do with them? Should it try to infer a corresponding `RangeIndex`? What should it do with inputs it cannot infer? _Decision: delegate all array inputs to `Int64Index`._
- [x] Should the `RangeIndex` constructor accept `dtype` as an argument? _Decision: accept, but only for array inputs._
- [x] If so, should it accept non-int64 dtypes as valid input? _Decision: Irrelevant due to delegation._ 
- [x] If so, does it need to check that the other inputs are within the range of the dtype? _Decision: Irrelevant due to delegation._
- [x] Related to constructor question, should slicing with a list return? Always `Int64Index` or `RangeIndex` when possible and `Int64Index` when not? _Decision: slicing with list will always return `Int64Index`._
- [ ] What should `RangeIndex(10).view('i8')` return? I believe `RangeIndex(10)`. _Decision: return `RangeIndex(10)`._
- [ ] What should `RangeIndex(10).view('i4')` return? I believe `Index(RangeIndex(10), dtype='i4')`. _Decision: return `Index(RangeIndex(10), dtype='i4')`._
