EAMxx: refactor field manipulation interfaces, and add new ones

[bartgol]

Simplify implementation of the scale/scale_inv method, and add new ones for max/min.

[BFB]

First, the current implementation had several methods implemented that could just be expressed as a single call to update, if only update accepted different combine mode values (like update_impl did). The solution was simple: template update on the combine mode, defaulting to the current behavior (i.e., ScaleUpdate). With this modification, scale, scale_impl and also deep_copy (from a Field rhs) could be rewritten as a 1-liner call to update.

Second, the PR adds two more values for CombineMode, namely Max and Min. The goal is to later use Field operations inside scorpio_output.cpp, to avoid manually handling the same kind of stuff in that class, simplifying its implementation.

Finally, allow do do stuff like y.scale(x) if y's data type is, say, double but x's data type is int (but not the other way around!).

[tcclevenger]

int->double conversions are going to be nice!

[bartgol]

@tcclevenger I added a few more improvements:

• Use MDRange instead of Range+modularArithmetics: I chatted with Jim about this (he faced this choice in RRTMGP a lot) as well as kokkos folks. I think the idea is that (with some caveats) MD should be faster if the tiling is right, and especially for small kernels, where the cost of doing index arithmetic may be comparable (or larger) than the actual calculation. I hacked in some timing for a rank-3 field update (200 cols, 2 components, 128 levs) and indeed MD range was faster (almost 2x). It may be that the pb was too small, or other factors, but since it wasn't noticeably slower, I opted for clarity and less code. Maybe one day I'll do that in the field property checks too, and do away with the unflatten_idx utility, which is the only reason why FieldLayout stores a kokkos view for the extents.
• Treat x and y separately when it comes to contiguity. This causes a duplication of template code instantiations, which is driving up compile time, but it makes sense to take advantage of contiguity if one of the two fields is contiguous, rather than use strided views for both...

The biggest rework compared to earlier is the CombineViewsHelper struct. I needed that on CUDA, since apparently you can't use an if constexpr inside a host-device lambda. So I had to create a functor.

[tcclevenger]

Seems like you are redefining MDRange in the scream::impl::CombineViewsHelper below instead of using this one?