Refactor window intersection and union

[groutr]

Window intersections and unions used suboptimal implementations.

wins = [windows.Window(i, i, 100-i, 100-i) for i in range(10)]
Intersect:
    
Old: %timeit windows.intersect(wins) 
141 µs ± 3.16 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

New: %timeit intersect(wins)
26.4 µs ± 2.13 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

Intersection

Old: %timeit windows.intersection(wins)
280 µs ± 5.07 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

New: %timeit intersection(wins)
24.9 µs ± 453 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

Union:
    
Old: %timeit windows.union(wins)
114 µs ± 6.2 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

New: %timeit union(wins)
24.4 µs ± 574 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

[groutr]

@sgillies Could I get a review on this?

[sgillies]

@groutr I'll take a look first thing next week. I'm on vacation now. How is this one related to #2162? Are they separate or dependent on each other?

[groutr]

@sgillies I didn't mean to interrupt your vacation. This is independent of #2162.

Two main things happen in this PR:

1. Removes the use of numpy when computing intersections and unions. It isn't really helping as much as it is slowing things down.
2. Remove the use of combinations from intersect. When we have 10 windows, it makes 90 (n!/(n-2)!) intersect computations instead of the (n-1) computations that are needed.

[sgillies]

👍

[sgillies]

@groutr combine these as the first is only called from the second?

[groutr]

I think you're referring to why I split the functions up the way I did.

The reasoning is as follows:
_compute_intersection: Compute the intersection directly. A low-level function that is useful in the case where it is not desired to create a Window object. This is useful in the case where the calling method is creating its own Window object or manipulating the values. Reviewing the function, it should probably be modified to also work on the tuple form of a Window.
_intersection: Compute an intersection and check if the intersection is empty. It is a higher-level function that is primarily designed to receive as input Windows and return a Window. This is what makes the reduce call possible.

I can combine them if you feel the current split is unnecessary.

[sgillies]

@groutr we deprecated the old tuple form at 1.0: https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L1082. No need to support it.

[sgillies]

Yes!

[sgillies]

@groutr what would you think about rebasing this on the master branch, for 1.3? That would protect us a little more from regressions.

[groutr]

@sgillies I rebased onto master. I'm fine with holding these changes for 1.3 as they don't directly fix any known bug.

[groutr]

@sgillies Is this PR still destined for 1.3.0?

[sgillies]

@groutr yes, thanks for the query!

[sgillies]

Let's do this! Thanks @groutr.