Fix __eq__, make arithmetic operations fully consistent with masked arrays, deprecate gu.misc.array_equal and bug fixes

[rhugonnet]

Summary

This PR modifies the behaviour of __eq__ to have a rigorous equality check between Raster objects.

As a result, a certain number of test failed linked to arithmetic operations, and thus a correction was made to _overloading_check and data.setter to avoid inconsistencies that were created in the masked arrays. Then, tests relying on __eq__ were updated to be more robust.

Additionally, the custom function gu.misc.array_equal initially introduced for back-compatibility and for which the behaviour was not clearly defined to all (it only checked valid data, but did not compare unmasked data, the mask themselves, or the dtypes as some of us expected) is now deprecated as similar functionalities exist in NumPy: np.array_equal(equal_nan=True), or np.ma.allequal, or in our new __eq__.

Finally, a small reprojection bug was fixed, a couple tests that did not work after the __eq__ update, and the type linting of Raster.astype that was missing a default parameter for one of its Literal.

Note: as the array_equal function lives in the same module as deprecate, I could not use the deprecate decorator (could only made it work from another module), so the function is removed entirely. I think this is fine as it is a "developer" function we use exclusively for tests, and not a "user" function.

Details

In details, this PR:

• Makes __eq__ compute an exact Raster equality, now considering masked values in data.data, the mask data.mask, the fill_value data.fill_value and the dtype data.dtype (called by to get the Raster dtype, so always matches);
• Fixes inconsistent arithmetic operation behaviour due to a forcing of dtype or an encapsulation by np.ma.masked_array in _overloading_check and data.setter to ensure the masked array operations with Raster always behave exactly like they would for arithmetic operation of masked arrays (the issue Strange behaviour of array_interface on mask and nodata setting #299 was triggered by passing a masked array as data=, i.e. first argument, into np.ma.masked_array. This happened in both data.setter and _overloading_check in some cases);
• Fixes behaviour of __array_ufunc__ (which takes over reverse arithmetic functions when array is passed first) because of exceptions in a few arithmetic functions (found a NumPy inconsistency!),
• Improves tests throughout test_georaster.py and test_satimg.py when checking raster or array equality: use __eq__ when relevant instead of array comparison, use double np.array_equal when both raw data and mask should be the same, or usenp.ma.allequal when valid data should be the same,
• Removes usage of gu.misc.array_equal that is now equivalent to np.ma.allequal but no needed for backwards compatibility (see Deprecate gu.misc.array_equal for np.array_equal and enforce Numpy>1.19 #290).
• Fixes reprojection issue and add tests (see Raster.reproject fails if res is numpy number #312).

Resolves #312
Resolves #299
Resolves #290

[rhugonnet]

Merging this to check if it solves the issue of xDEM, which is apparently not linked to nodata (still fails with -9999), but more likely dtypes during arithmetic operations (changed in this PR), and that I cannot reproduce locally...
I can account for comments in a separate PR, a posteriori.