ENH: print more detailed truncated sequence if a limit is given
works similar to numpy except that the edgeitems is overriden by threshold rather than the other way around which is what np does.

closes #3391 
- [x] add release notes

@y-p can u take a look-see please
 AH HA! i figured out the case where the overlap happens now i can write a test :) thanks @y-p for pointing that out
 @y-p 

numpy's `edgeitems` (a new option i'm introducing called `max_edge_items`) overrides `threshold` (equivalent to our `max_seq_items`), when `threshold < edgeitems`.

i don't think numpy's behavior in this regard is necessarily what a user would expect. personally, i would expect `max_seq_items` to be a "hard limit" on the number of items that `repr` _including_ the items `repr`'d on the edge of the sequence, thus i think `max_seq_items` should override `max_edge_items`. the `edgeitems` would then be forced to be _at most_ `n / 2` of the sequence, guaranteeing no overlap.

what do you think? this, of course, will not be consistent with numpy. right now the above described behavior is what i'm doing, but i can change if consistency with numpy is preferred.
 here's an example from the tests i've added:

``` python
with cf.option_context('display.max_seq_items', 2, 'display.max_edge_items', 5):
    s = 'Int64Index([0, ..., 9], dtype=int64)'
    res = repr(tm.makeIntIndex(10))
    assert_equal(s, res)
```
 I agree. when I suggested aligning with numpy I meant the format for summary: "foo foo foo ... foo foo foo", i.e.
symmetric. what you propose sounds right to me. 

As simple as possible but no simpler.
 for the special case of repring a `MultiIndex` when `max_seq_items == 1` i think the repr should be 

```
MultiIndex
[(u'C_l0_g0', ...), ...]
```
 Put constraints on the setting of of max_seq_items (even number >=2), and save yourself the special cases.
Yes, for MultiIndex, considering each tuple as an item makes sense.
 that certainly simplifies my life a lot
 @y-p  can u take a look when u get a chance? thanks
 @cpcloud close/push to 0.14?
 @cpcloud ?
 @cpcloud ?
 pushing to 0.14
 @y-p must have been accident
 It's stale, but it needs to happen for 0.14. If @cpcloud doesn't finish, I'll do it.
 @y-p gr8...i think i got all the accid closed ones...weird
 @cpcloud what's the state of this?
 I'll try to get this cleaned up this weekend.
 Something happened just now when I tried to update the remote .... getting the infinity commits again.
 Oh fudge I had those in a stash that has since been deleted .... ah well ... nothing major anyway. I'll open another PR.
