Add `export_fip_mapping()` one liner export

Currently the FIPNUM-Region-Zone mapping is exported in the following way:

Create xtgeo fipnum, region, zone GridPropertys from their respective RMS objects
Create a region table mapping region names to fipnums
Create a zone table mapping zone names to fipnums
Construct this into a Python dict as: {"FIPNUM": {"groups": {"REGION": region_table, "ZONE": zone_table}}}
Export this as a yaml file

This is done on a realization basis.

Simplification

We can compress these steps behind a simple export function.

export_fip_mapping(
    project: Any,
    grid_name: str,  # The RMS grid name, e.g. "Simgrid"
    zone_name: str,  # The RMS zone name, e.g. "Zone"
    region_name: str,  # The RMS region name, e.g. "Region"
    fip_name: str,  # The `FIPxxxxx` keyword, e.g. "FIPNUM"

    config_path: str | Path = "../../fmuconfig/output/global_variables.yml", 
    classification: str | None = None, # Actual default from config
)

This would, without changes, produce a fip.yml file in the following format:

FIPNUM:
  groups:
    REGION:
      CentralHorst:
        - 6
        - ...
      CentralNorth:
        - 3
        - ...
    ZONE:
      Therys:
        - 8
        - ...
      Valysar:
        - 1
        - ...

This format, with the mappings nested into groups, is particular to the format in use for the "old" Webviz:

https://github.com/equinor/fmu-tools/blob/1a30809bca592cf8e6e7e67b3be428a158540d20/src/fmu/tools/fipmapper/fipmapper.py#L509-L526

and we'd like to not nest into groups if possible. See Discussion.

We thought it might be best to store these on a realization level, since every realization generates them. Even if they are in practice the same for every realization, FMU is flexible enough to allow them not to be. Storing them this way is more durable and flexible to this reality.

This means consumers looking to establish this mapping on an ensemble level would need to select from one realization. This could be a reference realization or a random one (i.e. realization 0).

Context

Currently this mapping is exported on a realization basis.
- Assumption: This mapping does not change every realization
- This may usually be the case, but FMU doesn't allow it to always be the case.
This mapping/file format is not standardized across all models
- But, it is the input for Webviz, for fipmapper and for prtvol2csv
Mappings can be, and often are, hard coded
If they are not hardcoded they can be derived incrementally, i.e. a numerical increase over a loop
- There can be deviations for historical reasons, i.e. some FIPNUM breaks the ordering because it's "been that way" for years
- FMU technically allows stochastic region/FIPNUM ordering
- But, most likely this would be done on an ensemble basis rather than a realization basis

Uses

This produces fip.yml. This file is used for:

QC
Mapping reference for us poor humans
Comparing geovolumes with Eclipse volumes
fipmapper in fmu-tools
prtvol2csv to get zone/region columns added to the output
Webviz

Discussion

We should try to implement this without the groups key. Requires coordination with Webviz
- This might break compatibility with the "old" Webviz. Is this OK?
- It remains compatible with fipmapper
Currently exports use a top-level key of FIPNUM. This is hardcoded, no matter the actual FIPxxxxx Eclipse keyword used in the Drogon script. If we take this as an argument, presumably we will use it. Does it break compatibility elsewhere?
We dicussed uploading this as a json dictionary. But if this file is used as a yaml-input to other places (i.e. fipmapper), it makes sense to upload this as a yaml file. That is, it is a "valid file" we want to store rather than just metadata in a separate file and we may lose some "truth" by storing it as a json file.

Dependencies

Curently fmu-dataio does not support uploading yaml files
- We support dictionaries, and these dictionaries are stored as json
- However, technically, yaml can take forms that are not dictionaries (i.e., a list is the top-level structure)
Webviz as a consumer needs to confirm what formats are appropriate, or best for it

Relevant issues

Another similar format for this data is used within FMU as well: https://fmu-docs.equinor.com/docs/subscript/scripts/prtvol2csv.html#region-and-zone-support

equinor / fmu-dataio