Retrofit unit tests for fix_forecast_reference_time()

[truth-quark]

This issue follows on from issue #100 and PR #118.

PR #118 was reduced in scope to extracting the function & adding a very basic testing framework due to project handover requirements. This issue follows up to specify unit testing requirements:

Work on this PR needs to answer & address the following:

• Is the time.units.calendar == 'gregorian' code branch & testing required?
• Is the time.units.calendar == 'proleptic_gregorian' code branch & testing required?
• What inputs should be tested?
• What outputs should be tested?
• What cube state/attrs should be tested?
• Is the code branch covered by test_fix_forecast_reference_time_standard() required?
• Should the hardcoded 1600 for ref date year be a configurable function arg?
• @blimlim discussion on which branches to test
• Does a better solution exist than patching PPField.calendar at runtime?

These questions will help determine what work is required.

[truth-quark]

Random Saturday night thought, modifying PPField.calendar is a hack as it's essentially monkeypatching in production:

um2nc-standalone/umpost/um2netcdf.py

Lines 116 to 117 in 2587d84

	# TODO: Is dynamically overwriting PPField acceptable?
	PPField.calendar = pg_calendar

Being at the "root" level of the module, patching occurs at import time.

Question: would moving patching into a function help to:

• Control when patching occurs
• Provide unit testing benefits (e.g. make testing more deterministic as pre/post patching is controlled?)
• Make patching optional (e.g. if the original functionality is required)