Panel shift revert
Reverts #6605 closes #6959 #6826
## vs 13.1

```
-------------------------------------------------------------------------------
Test name                                    | head[ms] | base[ms] |  ratio   |
-------------------------------------------------------------------------------
panel_shift                                  |   0.0773 |   0.0990 |   0.7809 |
-------------------------------------------------------------------------------
Test name                                    | head[ms] | base[ms] |  ratio   |
-------------------------------------------------------------------------------

Ratio < 1.0 means the target commit is faster then the baseline.
Seed used: 1234

Target [3d0099a] : BUG: Change Panel.shift to use slice_shift #6605 #6826
Base   [d10a658] : RLS: set released to True. v0.13.1
```
## vs master

Note that the `pct_change is slower due to the deferred alignment. 

```
-------------------------------------------------------------------------------
Test name                                    | head[ms] | base[ms] |  ratio   |
-------------------------------------------------------------------------------
panel_shift                                  |   0.1650 | 522.0180 |   0.0003 |
panel_pct_change_major                       | 7615.9450 | 6213.1660 |   1.2258 |
panel_pct_change_minor                       | 7864.9763 | 5877.1353 |   1.3382 |
panel_pct_change_items                       | 8646.0753 | 5884.1163 |   1.4694 |
-------------------------------------------------------------------------------
Test name                                    | head[ms] | base[ms] |  ratio   |
-------------------------------------------------------------------------------

Ratio < 1.0 means the target commit is faster then the baseline.
Seed used: 1234

Target [3ec426f] : BUG: Change Panel.shift to use slice_shift #6605 #6826
Base   [0d2966f] : COMPAT:  32-bit platform compat for Panel.count
```

IIRC `pct_change` is doing this sectino by section (filling forward) and that is the issue here.

@TomAugspurger what do you think? 

as an aside let's make the vbench shorter so it takes at most 1000ms
 Anyone else get random travis failings on asserts that should pass?

```
======================================================================
FAIL: test_sum (pandas.tests.test_frame.TestDataFrame)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.6_with_system_site_packages/lib/python2.6/site-packages/pandas/tests/test_frame.py", line 10590, in test_sum
    has_numeric_only=True, check_dtype=False, check_less_precise=True)
  File "/home/travis/virtualenv/python2.6_with_system_site_packages/lib/python2.6/site-packages/pandas/tests/test_frame.py", line 10780, in _check_stat_op
    check_less_precise=check_less_precise)  # HACK: win32
  File "/home/travis/virtualenv/python2.6_with_system_site_packages/lib/python2.6/site-packages/pandas/util/testing.py", line 513, in assert_series_equal
    assert_almost_equal(left.values, right.values, check_less_precise)
  File "testing.pyx", line 58, in pandas._testing.assert_almost_equal (pandas/src/testing.c:2554)
  File "testing.pyx", line 93, in pandas._testing.assert_almost_equal (pandas/src/testing.c:1796)
  File "testing.pyx", line 140, in pandas._testing.assert_almost_equal (pandas/src/testing.c:2387)
AssertionError: expected 0.00144 but got 0.00144
```
 @dalejung I have seen this one a few times....I think its just a precision issue, can iu nvestigate?
 Yar. I'll track it down. 

Sent from my iPhone

> On Apr 27, 2014, at 10:31 AM, jreback notifications@github.com wrote:
> 
> @dalejung I have seen this one a few times....I think its just a precision issue, can iu nvestigate?
> 
> —
> Reply to this email directly or view it on GitHub.
