mordernize maxtree-based operations

[johnnychen94]

Following the spirit of the recent SE concept improvement, I plan to revisit the API and implementation of maxtree-based operations: area_opening, area_closing, diameter_opening, diameter_closing, local_minima, local_maxima, local_extrema.

The proposed changes:

1. make max tree an image, i.e., a subtype of AbstractArray -- in this sense, a max tree image is just an image with pre-built metadata.
2. support generic SE for max tree construction -- I have positive intuition but I'm not 100% percent sure if this is doable
3. API: f(img, [maxtree]; connectivity) => f(img, se)

@ThomasRetornaz asked in #60 (comment)
Question i let the code regional maxima/minima even it will produce the same results than local_minima/maxima from maxtree but in a faster way do we keep boths?

If handled well, I believe the API change could answer the question:

# let the internal implementation figure out a better algorithm
# the decision might be based on empirical benchmark results, however
local_maxima(img, se)

# explicitly use the MaxTree implementation
img_maxtree = MaxTree(img, se)
local_maxima(img_maxtree)

Once we sort out how to handle this issue, I believe there is nothing blocking #60

[ThomasRetornaz]

For maxtree approach there is no interest of handle generic SE, eg the se is just used in a bool isconnected(pixel,neigborhoodPixel) function to build the initial tree (same for connected component). It will use V4 (diamond) or V8 (box) connection to create the neighborhood graph
But i think the maxtree implem could be speed up using path compression and union by rank (see https://www.algotree.org/algorithms/disjoint_set/)

I thibk that i have to redisgn #60 to handle new SE deffinition and yes the proposed implem in #60 is faster than maxtree approach if maxtree is not prebuilt I will ensure that with benchmark :)