Refactoring Coriolis implementation and semantics

[tomchor]

I'm opening this issue based off of the long discussion about semantics and implementation of the Coriolis acceleration in #1892.

@glwagner correct me if I'm wrong in the description of the issues since I'm not sure I 100% understand them.

Currently we have (with some oversimplifcation):

• FPlane
• ConstantCartesianCoriolis
• BetaPlane
• NonTraditionalBetaPlane
• HydrostaticSphericalCoriolis

Which is kind of a lot. Two issues that are not separate from each other are

• The names don't have much consistency between themselves and are at times a bit obscure (a new user might ask what is a non-traditional β-plane, or a cartesian coriolis)
• In the current system we need to have different abstractions for Coriolis accelerations (hence the large number of abstractions) for different coordinate systems because we need to store different data for calculations in different grids

A way to improve on both issues might be to have only one or two abstractions for background rotation only. So instead of storing, for example, each cartesian component of f for ConstantCartesianCoriolis or just the rotation rate and a scheme for HydrostaticSphericalCoriolis, we would only need to store a rotation_axis and a rotation_rate (or equivalent; plus possibly the scheme?).

The difficulties I could perceive are that different grids require different calculations so we'd need to dispatch on grid type (such as here

Oceananigans.jl/src/Coriolis/hydrostatic_spherical_coriolis.jl

Lines 30 to 31 in 32c5c5a

	@inline φᶠᶠᵃ(i, j, k, grid::RegularLatitudeLongitudeGrid) = @inbounds grid.φᵃᶠᵃ[j]
	@inline φᶠᶠᵃ(i, j, k, grid::ConformalCubedSphereFaceGrid) = @inbounds grid.φᶠᶠᵃ[i, j]

and also that the calculation apparently needs to take into account whether or not the flow is hydrostatic, so we may need to dispatch on model too? (Plus some possible complications about the pressure solver.)

CC @glwagner @francispoulin

[glwagner]

I think what we need to do is to distinguish between "hydrostatic" (as a proxy for "thin aspect ratio") and "nonhydrostatic" (non-thin-aspect ratio) approximations.

Then our API would provide types for Coriolis forced induced by rotation at a constant rate:

• NonhydrostaticCoriolis
• HydrostaticCoriolis

By storing rotation_axis (a 3-tuple in the coordinate system associated with the user-specified grid) and either a rotation_rate or total magnitude f, both of these types can be "coordinate-system agnostic", and work with either a spherical or Cartesian coordinate system (the two we plan to support moving forward).

Then there are two more types associated with the so-called "beta" plane. These could keep their original name, or we can change "NonTraditionalBetaPlane to NonhydrostaticBetaPlane.

@navidcy has argued that it's worthwhile to keep FPlane and BetaPlane as is because of their familiarity and ubiquity in oceanography. I think I agree with that.

[glwagner]

The difficulties I could perceive are that different grids require different calculations so we'd need to dispatch on grid type

I think this is ok. We can dispatch on both the grid (and its associated coordinate system) and typeof(coriolis) to infer the Coriolis model. I think such a design is good because it is code-efficient.

[glwagner]

I think this is done