SRGR conversion for WSM modes

[priit111]

SAR geocoding works by mapping the on ground coordinates(DEM) and orbit state vector metadata to create azimuth time(azimuth index) and slant range time(range index) mapping. sarsen uses this data to interpolated the source product to a geocoded product. This conversion is easier with slant range products as the slant range of the source product is the same used for geocoding interpolation. However with ground range product the ground range index of the source is only mapped to slant range via source range product SRGR/GRSR polynomials.

Since sarsen does not do per pixel calcuations, it needs to be described via xarray coordinates. S1 sarsen performs a SRGR conversion of the geocoding result to perform the actual geocoding interpolation(https://github.com/bopen/xarray-sentinel/blob/efda399523e39fdfe0b3e3cd7f321dc144a9e90b/xarray_sentinel/sentinel1.py#L1089). Unfortunately the Envisat file format only contains GRSR polynomials.

With a single GRSR polynomial(like IMP/APP products) a solution was found, where the source product range direction slant range indexing for xarray dataset is non-linear. This works fine and is a nice solution to avoid the sarsen S1 GRSR conversion approach. Unfortunately a WSM product is a very large one and contains multiple GRSR polynomials, each with a azimuth time point as a reference. Current implementation tries to generate SRGR polynomials itself.

1. Find a solution to have xarray support non-linear coordinates of the source product with varying GRSR polynomials.
2. Improve the accuracy of the GRSR -> SRGR conversion done manually in the WSM support code. Current implementation produces some error, needs further study if this is a problem or not.

[priit111]

Particularly the point 2. is visible via warnings "RankWarning: Polyfit may be poorly conditioned" when processing WSM datasets, however this needs further study to get the GRSR -> SRGR polynomial to be accurate.