Refactor interfaces and internal state of adjoint module objective quantities

[ianwilliamson]

This PR picks up where #1588 left off with some refactoring of the mpa.ObjectiveQuantity child classes:

• Many attributes of the mpa.ObjectiveQuantity child classes are not correctly indicated as being private
• Some attributes of the mpa.ObjectiveQuantity child classes (e.g. source in EigenmodeCoefficient) should apparently not even be part of the internal state (since they're unused) and are initialized in an adhoc manner throughout different methods of the classes
• Functions such as adj_src_scale() and create_time_profile() should actually be methods of mpa.ObjectiveQuantity

In an effort to streamline the process of debugging tricky issues such as #1585, the interfaces, attributes, and data marshaling in the adjoint module should be standardized in the mpa.ObjectiveQuantity.

[ianwilliamson]

Okay, I think this should be good to go on my end.

[smartalecH]

Many attributes of the mpa.ObjectiveQuantity child classes are not correctly indicated as being private

Many of these quantities don't need to be private, do they? From a flexibility perspective, this seems restricting.

[ianwilliamson]

Many of these quantities don't need to be private, do they?

These objects use a lot of internal state to pass information between various steps (registering monitors, performing fwd and adjoint sims, etc) and if that state isn't supposed to be accessed/modified by external code then, yes, they need to be marked as private.

Part of the goal here is to indicate to tools, such as pylint, what the intended data access patterns and APIs are. Pylint can then help us to identify bugs through static analysis.

From a flexibility perspective, this seems restricting.

There is nothing preventing you from querying these variables in environments such as colab. If there's something missing from the public API that's needed by some other piece of unchecked in code, we can incorporate that. Let me know if there's something specific.