Remove need for `openCV` in `write_evr` by implementing C++/Cython/Numba accelerated contour finding

[ctuguinay]

In #225 I added write_evr capability. Currently, openCV is used to do the contour finding in write_evr. I spent some time trying to write different contour finding algorithms in numpy, but these were rather slow compared to openCV (and scikit-image) implementations since they were C++/Cython accelerated. ~12seconds vs ~0.1seconds for a 3955 x 1681 matrix ended up being the time comparison. The problem with installing openCV is that it drastically inflates the size of the Echoregions package, which is supposed to be lightweight, so we'll need to implement some form of contour finding in the future.

The algorithm which openCV uses is Suzuki-Abe and this algorithm works well with holes. It's rather involved to implement, so I'll need to heavily reference openCV's implementation (https://github.com/opencv/opencv/blob/master/modules/imgproc/src/contours.cpp) to do this. Another option to try is an accelerated version of Moore-neighborhood tracing algorithm, which doesn't work well with holes, but with path simplification, can be robust as Suzuki-Abe in contour tracing of regions containing no holes.

[ctuguinay]

I think if this works out, another thing to do on Echoregion's side is the ray-casting that GEOS is currently doing through the regionmask package. The sequentially implemented linear time ray-casting seems to be the bottleneck in the region_mask and the bottom_mask functionality. There's a few faster log time algorithms that speed up the inclusion algorithm via partitioning, found in Computational Geometry--An Introduction (Preparata 1983).

[leewujung]

@ctuguinay : I am thinking it may be useful to keep the openCV implementation as an option/alternative even after you implement something into the echoregions package -- of course unless you mean to implement the same algorithm as in openCV? Although that seems would create more work in the long run to maintain/upgrade, compared to just levearge openCV support.

[ctuguinay]

@leewujung Oh yeah good idea. I was planning on doing a simpler version of Suzuki-Abe or Moore-neighborhood, but yeah, I agree that users should also have the option to use the more robust openCV implementation if they want to install openCV.

[ctuguinay]

I think we'll just stick with openCV. No need to recreate this.