Fix invalid or corrupt geometries in data sources that have them

[florisvdh]

This applies to the next data source versions (2023); wouldn't do this anymore for current data sources. It was observed that at least QGIS can struggle with this. After fixing geometries in R (st_make_valid()), the below job ran. In #50 (comment) we had decided not to do the fix. However this observation shows we'd better done that.

EDIT: further reference is #54 (comment)

Further background: https://r-spatial.org/r/2017/03/19/invalid.html, and updates indicated by https://r-spatial.github.io/sf/news/index.html#version-09-0 and r-spatial/sf#989 (note that only lwgeom::lwgeom_make_valid() still reflects sf::st_make_valid() behaviour at the time of the r-spatial tutorial, i.e. for the corrupt geometry p[5]).

[florisvdh]

My current view on this:

• raw data sources: add a logical argument in the {n2khab} reading functions to optionally fix geometries on the fly (on condition that this is a computationally feasible step for these datasets). Not by default: because we want to stay close to the original (raw) by default and also for backward consistency (cf. former behaviour for existing data source versions).
• processed data sources: always fix the geometries – i.e. in upcoming versions. For watersurfaces_hab (version watersurfaces_hab_v4) this has been done on an as-needed basis (50ae4b4) by @cecileherr.

[florisvdh]

Successfully tackled by @cecileherr for the upcoming 2023 version of habitatmap derivatives, and the associated n2khab::read_habitatmap() function. For watersurfaces_v1.2 this was handled by PR inbo/n2khab#168.

Leaving this issue open since there are several more raw data sources that may need this.