Add common angle/solid-angle units to units namespace

[bartgol]

Motivation

rad is used a lot in E3SM, and users need to inject code like

Units rad (ekat::units::Units::nondimensional(),"rad")

which is not super-clear. It'd be clearer to just use ekat::units::rad directly.

Also, added a rename method, so one can do

auto m2 = (m*m).rename("m2");

which I think it's clearer (in intent) than

Units m2(m*m,"m2");

Finally, i removed dyn and rem, as they are non-SI units, but unlike g (which is used) they seem to be quite niche.

E3SM Stakeholder Feedback

Testing

[Copilot]

Pull request overview

This PR extends EKAT’s units utility by adding commonly used angle/solid-angle symbols to the ekat::units namespace and introducing a convenience API for renaming derived units’ string representations.

Changes:

• Added Units::rename(std::string_view) to retag a unit’s string representation while preserving its dimensions/scaling.
• Added ekat::units::rad and ekat::units::sr as named dimensionless units for angle and solid angle.
• Refactored several derived-unit declarations to use rename(...), and removed dyn and rem unit constants.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bartgol]

This PR turned into a more general cleanup of the Units class and units namespace:

• add rad, sr, and none constants
• deprecate Units::nondimensional() (use constant instead.
• deprecated rem and dyn (non-SI and VERY niche). Btw, dyn's numerical value was wrong, fixed it.
• remove global array of basic units symbols
• use string_view when possible
• added is_scaled (parallel method to is_dimensionless).

[mahf708]

shouldn't the derived units belong to the downstream app/customer?

[bartgol]

shouldn't the derived units belong to the downstream app/customer?

That's one way to approach the issue. In general, yes, but I find it "reasonable" to provide some "common" ones (like N, Pa, J, W, etc).