Reconstruct a full GRTSmaster_habitats grid

[florisvdh]

The current GRTSmaster_habitats (raw) data source is a clip, following Flemish borders, out of a complete GRTS grid. However, the latter has only ever existed in a computer's RAM, about > 10 y ago, and was not saved.

Because there are unwanted side-effects of this (problems in assigning GRTS addresses to lines and points near the Flemish borders), this needs a better solution than incorrect workarounds.

Plan:

• reconstruct a new, full GRTSmaster grid, being defined as a new version of GRTSmaster_habitats, but constrained on the GRTS addresses already present (i.e. the existing ones are kept, while respecting the GRTS approach for the whole grid). The algorithm is not difficult; technical implementation or execution may be a bit more challenging.
  • it will be more logical to regard the base4frac variant (GRTSmh_base4frac) as the raw data source (it has the actual GRTS addresses), and the decimal variant GRTSmaster_habitats as the processed one. It will result in flipping Zenodo membership 'raw' vs. 'processed'.
• derive new processed data sources of both full grids (base4frac / decimal), which again are clipped versions, however now applying a substantial buffer (1 km?) around the Flemish borders. Their names could be GRTSmh_buffer and GRTSmh_base4frac_buffer. For convenience / historical consistency, the decimal clipped variant should be the data source returned by default by read_GRTSmaster_habitats(), and likewise for the base4frac clipped data source (read_GRTSmh_base4frac()).
• accommodate the now full grids GRTSmaster_habitats and GRTSmh_base4frac in read_GRTSmaster_habitats() and read_GRTSmh_base4frac() respectively, but don't return them by default.
• derive new (clipped with buffer) version of GRTSmh_brick (decimal) and accommodate in read_GRTSmaster_habitats()
• derive new (clipped with buffer) version of GRTSmh_diffres (decimal) and accommodate in read_GRTSmh_diffres()