Massive refactor of MARBL for MARBL 2.0?

[mnlevy1981]

@matt-long and I were talking about future versions of MARBL and what sort of modularity would be best suited for flexibility in how the library is configured. For example, one goal of the MARBL project is to be able to easily configure a simple model with a reduced number of tracers and forcings. Maybe instead of the current paradigm, where all tracers are kept in a tracer data type, it would make more sense to refactor the interface so that data is clumped by element type. The carbon type would contain all the tracers, diagnostics, and carbon-dependent processes, the oxygen type would contain the same for oxygen, and so on. Want to run a simple "carbon-only" case? Tell MARBL to initialize the carbon type but none of the others.

One of the things that came up when Matt and I talked about was the current state of the build system. Coming up with a more flexible build system (perhaps CMake?) is a good first step to take -- it will let us easily specify how to build different configurations, while also possibly highlighting build-time dependent aspects of the library that could be run-time configurable instead.

As the title of this ticket says, this would likely be a huge change to the code base. Obviously this won't even be considered until we have a stable MARBL v1 release, but this seems like a good place to discuss whether this is a good path forward and also leave notes to our future selves about what obstacles we can expect to encounter.