Simple fix for incorrect "wraparound" catalog properties

Here's a first crack at addressing #120, which noted that when a structure "wraps" around in coordinate space, its computed properties are broken.

This implementation (which is currently overly simple) checks to see if `dendrogram.neighbours` is anything other than the vanilla `Dendrogram.neighbours`. If it is, it assumes that you want to wrap in longitude space. Whenever it finds that you're computing stats on a structure that touches the "minimum" and "maximum" extents of the data, it assumes that it's a wraparound structure and shifts the bottom indices up by the length of the data. Later I'll want to make sure that the resultant computed properties (such as the x_cen, whatever) are within the bounds of the data (so e.g. I'd mod them by `wrap_longitude`)

For control, I've introduced an extra keyword "wrap_longitude" which percolates from `ppv_catalog` down to `ScalarStatistic`, but this wouldn't be the permanent name or form of such a variable.

Any thoughts on whether this implementation is heading in the right direction are welcome.
On further reflection, a better test might be to test whether the structure straddles the outer 2 quadrants:

```python
quad = (index_array / (shape / 4)).astype(int)
quadct = np.histogram(quad, [-0.5, 0.5, 1.5, 2.5, 3.5])[0]
if quadct[0] > 0 and quadct[1] == 0 and quadct[2] == 0 and quadct[3] > 0:
...
```

This protects against situations where very large structures in non-periodic images satisfy the ptp() test by chance, and are inappropriately wrapped