Need to rebase after #333 merges.

We could actually make this non-breaking by making some small adjustments to the ClimaODEFunction constructor, and just forwarding post_explicit!/post_implicit! keywords to the pre-functions, knowing that users must be using the same function for their code to work correctly anyway.

I would advise against using either pre_explicit or post_explicit, as that does not accurately describe what this function will do. The correct name for this function is either post_stage (preferred) or pre_tendency (usually correct, except at the end of the last timestep, since there are no further tendencies to compute after that). The other function can be called pre_implicit, but it would be more correct to call it pre_implicit_solve, since the implicit tendency for each stage will still be computed with post_stage/pre_tendency.

As I mentioned in #322, post-anything is a bad name in that it's describing the implementation detail, and not what the function actually does-- it pre-computes variables that are shared between multiple function calls with the same state and at the same time (since we know that then, and only then, the cache should be the same). So, I'm now pretty firm on removing post from all of the names.

pre_tendency sounds nice, but also ambiguous, which tendencies are to be shared? Part of what makes exposing these hooks complicated is that they arise from implementation details-- different step! implementations will allow for sharing the cache between multiple function calls in different ways. Perhaps we should see if we can pass functors like SharedCache(wfact!, implicit_tendency!) to ClimaODEFunction, and then that would indicate to the time-stepper that the user could compute the cache for both implicit_tendency! and wfact! with that functor call.

I'm also not really in favor of allowing pre_explicit and pre_implicit to be used as aliases for these new functions, as that will almost certainly lead to confusion and bugs in the future. Those names are not indicative of how these functions will be used, so we should probably just make this a breaking change.

I agree, I was just trying to avoid breaking changes. I think the cleaner thing will be to just fix this bug and make a breaking release.