CI: Set environment cache key based on current week of year to avoid outdated cache in the "Setup Micromamba" step

[seisman]

Take the latest run of the "Tests" workflow on the main branch as an example. The "Setup Micromamba" step in the "Ubuntu + Python 3.10" job uses the cache with key micromamba-environment--linux-64-pygmt-args-4fc7725-root-dcc80ee, which was cached last month as shown here (https://github.com/GenericMappingTools/pygmt/actions/caches).

The setup-micromamba action says (https://github.com/mamba-org/setup-micromamba#caching):

Note that the specified cache key is only the prefix of the real cache key. setup-micromamba will append a hash of the environment file and the custom-args as well as the environment name and OS to the cache key.

And GitHub says (https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy):

GitHub will remove any cache entries that have not been accessed in over 7 days.

So, the cached environment won't be refreshed unless we make changes to the packages listed in the create-args argument. We're using outdated packages in our workflows, which explains why sometimes we see old packages installed in CI.

The solution is to define the cache key based on the current date.

We can define the cache key like micromamba-environment-2024-05-07, which means the cache will expire on the next day so the first CI run on the next day will be slower since the cache is missing. I feel one day is a little too short for PyGMT, so in this PR, the cache key is defined like micromamba-environment-2024-W19, in which 2024-W19 means the 19th week of 2024. The cache will persist for one week.

Patches #2946.

[seisman]

With the latest packages installed, now we can also see the Fiona errors reported in #3180 (comment)

______________ test_geopandas_info_shapely[multipolygon-desired0] ______________

geojson = <MULTIPOLYGON (((0 0, 20 0, 10 20, 0 0), (3 2, 10 16, 17 2, 3 2)), ((6 4, 14...>

    @contextmanager
    def tempfile_from_geojson(geojson):
        """
        Saves any geo-like Python object which implements ``__geo_interface__`` (e.g. a
        geopandas.GeoDataFrame or shapely.geometry) to a temporary OGR_GMT text file.
    
        Parameters
        ----------
        geojson : geopandas.GeoDataFrame
            A geopandas GeoDataFrame, or any geo-like Python object which
            implements __geo_interface__, i.e. a GeoJSON.
    
        Yields
        ------
        tmpfilename : str
            A temporary OGR_GMT format file holding the geographical data.
            E.g. '1a2b3c4d5e6.gmt'.
        """
        with GMTTempFile(suffix=".gmt") as tmpfile:
            import geopandas as gpd
    
            Path(tmpfile.name).unlink()  # Ensure file is deleted first
            ogrgmt_kwargs = {"filename": tmpfile.name, "driver": "OGR_GMT", "mode": "w"}
            try:
                # OGR_GMT only supports 32-bit integers. We need to map int/int64
                # types to int32/float types depending on if the column has an
                # 32-bit integer overflow issue. Related issues:
                # https://github.com/geopandas/geopandas/issues/967#issuecomment-84287[770](https://github.com/GenericMappingTools/pygmt/actions/runs/8981820061/job/24669172952?pr=3234#step:8:771)4
                # https://github.com/GenericMappingTools/pygmt/issues/2497
>               if geojson.index.name is None:
E               AttributeError: 'MultiPolygon' object has no attribute 'index'

../pygmt/helpers/tempfile.py:142: AttributeError

During handling of the above exception, another exception occurred:

>   ???

fiona/ogrext.pyx:136: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

>   ???
E   fiona._err.CPLE_OpenFailedError: <fiona.io.MemoryFile object at 0x7f843fe3d410>: No such file or director

[seisman]

Ping @GenericMappingTools/pygmt-maintainers for comments before I apply the same changes to other workflows.

[seisman]

This workflow is only scheduled to run weekly. We don't care about the speed of the workflow, so no need to cache the enviroment.