Expose marine regions version

[brynpickering]

Closes #82

Open Q: do we want to label output files with this version as we do with some of the others? It's unnecessary right now as we limit it to a single version.

Reviewer checklist

• There are no pip dependencies in the module's environment files (workflow/envs/).
• All rules use pathvars (e.g., <results>) in their inputs and outputs.
• The integration test-suite is successful, including:
  • pre-commit.ci tests pass.
  • tests pass for all relevant OS configurations (linux, osx, windows).
• Module documentation is up-to-date, including:
  • INTERFACE.yaml mentions all relevant pathvars and wildcards.
  • README.md describes how to use the module and has the necessary citations.

[irm-codebase]

Thanks for the submission @brynpickering!
To maintain the principle of re-usability of 'harmonised' files, I'd say it's a good idea to label them with the requested version, yeah.

[irm-codebase]

Looks good overall!

Only thing I suggest is moving from a 'hard cap' (version==2.0.0) to a more permissive 'lower cap' (version >= 2.x.x). This allows us and users to try updating the EEZ version without needing to update the module version.

[irm-codebase]

I did not know you could pass temp() outside the call!
Does it work?

[brynpickering]

No, this crept in from a test I did. I should delete it.