Add test for new dependencies

[Sbozzolo]

Adding new dependencies to a Julia project has downsides. First, every dependency increases the precompilation and import time of a package. For complex packages, such as CUDA, this translates in several minutes of precompilation time that every single user of ClimaAtmos (including our CI runners) always pays. Second, dependencies can increase the cost of maintaining ClimaAtmos and the surface area of things that can go wrong (a buggy update in a dependency can break ClimaAtmos). Third, dependencies increase the complexity of the project's environment, potentially causing compatibility issues and restricting the versions we can use.

This new test follows the spirit of the allocation tests and tries to capture the cost of adding a new dependency by having developers explicitly edit the file.

The only relevant commit in this PR is 68bb3f7

Everything else is #3276, where I remove some unused dependencies

[charleskawczynski]

I'm not sure how I feel about 68bb3f7. Is this really something that we want to have a test for?

[Sbozzolo]

It is much easier to keep dependencies out than to remove them once they are in. So, I would like people to be more mindful of what they are adding and check if the new dependency is really needed.

Several people work on ClimaAtmos and currently there is no barrier to adding new dependencies. Two examples of things that I removed over the past few months that should have never gotten in: Distributions.jl (not a small library) to compute an error function, an entire image processing stack to perform a gaussian filter (through ImageFiltering). To add a tiny barrier, I follow the idea of the allocation tests, where we add a bit of friction for people to stop for a second looking at what they are doing.

[charleskawczynski]

It is much easier to keep dependencies out than to remove them once they are in. So, I would like people to be more mindful of what they are adding and check if the new dependency is really needed.

Several people work on ClimaAtmos and currently there is no barrier to adding new dependencies. Two examples of things that I removed over the past few months that should have never gotten in: Distributions.jl (not a small library) to compute an error function, an entire image processing stack to perform a gaussian filter (through ImageFiltering). To add a tiny barrier, I follow the idea of the allocation tests, where we add a bit of friction for people to stop for a second looking at what they are doing.

That's a fair point. I'm willing to try this if other people are okay with trying it. I'll request additional review

[charleskawczynski]

Ah, there are more reviewers listed. @dennisYatunin, @sriharshakandala, can you please chime in?

[Sbozzolo]

(I do agree that this should not be a test: it should be reviews that capture this sorts of problem, but we are not there yet)

[dennisYatunin]

I discussed this with Gabriele offline a few days ago. My thoughts are that it is ok to add something like this if unnecessary packages keep making it past review, though I think we could also get away with something a little more automated (e.g., compare the list of currently loaded packages to what's on main or in the latest release, and print a warning if the currently loaded list has anything extra).

One feature of this version that the automated version wouldn't capture, however, is that it provides a central place for people to jot down why specific packages need to be added and where they are used. Ideally, we could do this directly in Project.toml, but any comments in that file get overwritten when it is modified by the package manager.

If we want to include this as part of the design, I think the version of the test added in this PR is fine. If not, we can fix Pkg.jl so that it doesn't remove comments from Project.toml, and then we can put package-related notes in that file and turn this test into a simpler automated warning.

[Sbozzolo]

Ok, I am merging this. We can revert it or change our approach if it causes troubles or other unintended consequences.