BUG: Fix segfault on isnull(MultiIndex)
Now raises NotImplementedError b/c not yet clear what it should return.

Fixes #5123.

cc @TomAugspurger 
 I tried your branch and your fix worked.  Thanks.
 okay, so any objections to raising NotImplementedError here?
 no objections ... can u remove the unused `_test` import?
 oh nevermind, wrong file
 One benefit of changing MI representation to _not_ be a subclass of ndarray will be to avoid issues like these. I'm pretty sure there are other methods where this is an issue as well.
 > One benefit of changing MI representation to not be a subclass of MultiIndex

Do u mean `Index`?

segfault is happening bc MI shape is 0 and a length 0 array is ultimately passed to `lib.isnullobj` which is not doing a manual bounds check before trying to access elements and it probably has the `@cython.boundscheck(False)` decorator enabled

why not just return a `MultiIndex` with `True`, `False`?

``` python
def _mi_is_null(mi):
    values = mi.values
    avalues = np.array(lmap(list, values), object)
    null = isnull(avalues)
    return MultiIndex.from_arrays(null, names=mi.names)
```

though the utility of this isn't so clear to me...why would you pass a `MultiIndex` to `isnull` in the first place? i agree with notimplementederror, but i also think at some point we should decide to return something and not raise
 I meant ndarray.
 @cpcloud can we save that for 0.14 instead of choosing what it should return now? It's sort of the same thing as bool on an NDFrame. It could either be True if _any_ value on any level at a location were NaN, or True only if _all_ were NaN at that point.

Also, the MultiIndex returned by `from_arrays` like that would be nearly unusable, given that it would just be a huge number of dups (only can take True or False  on each level). Better to just return the ndarray instead.
 agree with all those points ... i think ndarray is a better return there
 merge this?
 I doubt has a perf impact but maybe give a quick test
 okay, do you want to just leave this for 0.14 when MI won't be a subclass of ndarray and the problem won't exist (because we'll have to add a check to isnull regardless)?
 no, I actually think this needs to be in 0.13 (at least for the moment to avoid the segfault). I am going to post a perf check soon (though as I said I don't think this is a problem....but anytime I change stuff in heavily used routines can't hurt to check)
 okay - sorry to pass the buck, I just don't trust my machine to do perf tests well. If I get my hands on a non-laptop then I could trust it.
 no..prob
 other option is to do:

``` python
values = getattr(obj, 'values', obj)
```

and then add view(cls) at end, but you get more metadata issues and such.
 this is fine perf wise....go ahead and merge
 go ahead and merge this
 @jtratner this mergeable, right?
 Yeah, I just rebased it, hopefully it'll just pass.
