BUG: fillna with method segfaults on zero-length input (fixes #2775)
fixes #2775

just added a check for zero-length data to the backfill and pad templates

not sure if I should add test coverage? the problem is that the tests will not fail without the fix, but rather segfault, so it might not be a good idea

fyi....this is going to conflict with dtypes branch....maybe do this afterwards? #2708
 do you want to just fix it on your branch instead and we can close this PR? it's just some checks for N == 0
 sure...just pad & backfill (all methods)....do we have a test to replicate?
 just run `fillna` on any `DataFrame` or `Series` with zero rows, using a method rather than a fill value...
example from original issue was `pandas.DataFrame(columns=["x"]).x.fillna(method="pad", inplace=1)`
 I don't think inplace is needed to trigger, and I was unable to replicate with Series().fillna(method="pad", inplace=1)

Not sure why pandas.DataFrame(columns=["x"]).x and series() behave differently, there may be a deeper issue
at play.
 it triggered for me with and w/o inplace....adding as a test
 ok...fixed in #2708
 fyi, apparently it only segfaults when `dtype=='object'`, probably because that's the only case in which the value is dereferenced as a pointer. for non-object dtypes, the bug is still there, but it doesn't cause a segfault because the memory is just being read and interpreted as an integer/float

``` python
In [2]: p.Series().dtype
Out[2]: dtype('float64')

In [3]: p.Series().fillna(method='pad')
Out[3]: []

In [4]: p.DataFrame(columns=['x'])['x'].dtype
Out[4]: dtype('object')

In [5]: p.DataFrame(columns=['x'])['x'].fillna(method='pad')
Segmentation fault (core dumped)
```

``` python
In [2]: p.Series().astype('int64').fillna(method='pad')
Out[2]: []

In [3]: p.Series().astype('object').fillna(method='pad')
Segmentation fault (core dumped)
```
 Should this be patched in a v0.10.2 release? I think that might happen before #2708 is merged into v0.11 dev branch
 up 2 you....it actually hard to trigger this (though fix is pretty trivial too)...
 @wesm, i restored the branch and commited the same test as in #2708, in case you want to merge this first. there will probably be conflicts later if you do, but they'll be easy to resolve
 closed because of merge of #2708
