add function to normalize all time coord units

[jtmims]

Description
@nishsilva found an issue (#730) where his data couldn't get through crop_date_range. This was caused by the fact that the calendar attribute was hidden in the encoding of the time coord. After this, a new function had to be made to allow files that have differing time_units to pass through the preprocessor.

Associated issue #730

How Has This Been Tested?
Tested with ECMWF-LR output on my workstation to launch Nish's POD. I also tested the seaice_suite and Wheeler_Kiladis.

Checklist:

• My branch is up-to-date with the NOAA-GFDL main branch, and all merge conflicts are resolved
• The scripts are written in Python 3.12 or above (preferred; required if funded by a CPO grant), NCL, or R
• All of my scripts are in the diagnostics/[POD short name] subdirectory, and include a main_driver script, template html, and settings.jsonc file
• I have made corresponding changes to the documentation in the POD's doc/ subdirectory
• I have requested that the framework developers add packages required by my POD to the python3, NCL, or R environment yaml file if necessary, and my environment builds with conda_env_setup.sh
• I have added any necessary data to input_data/obs_data/[pod short name] and/or input_data/model/[pod short name]
• My code is portable; it uses MDTF environment variables, and does not contain hard-coded file or directory paths
• I have provided the code to generate digested data files from raw data files
• Each digested data file generated by the script contains numerical data (no figures), and is 3 GB or less in size
• I have included copies of the figures generated by the POD in the pull request
• The repository contains no extra test scripts or data files

[wrongkindofdoctor]

@jtmims This should accommodate cases where units are leap seconds (not common, but that doesn't mean we won't see it).

[jtmims]

I have pushed new commits which adds logic to handle multiple types of time units