Improved FunctionalAffect alternative

[BenChung]

Checklist

• [x] Appropriate tests were added
• [ ] Any code changes were done in a way that does not break public API
• [ ] All documentation related to code changes were updated
• [ ] The new code follows the contributor guidelines, in particular the SciML Style Guide and COLPRAC.
• [x] Any new documentation only uses public API

Additional context

This introduces MutatingFunctionalAffect (better name suggestions much appreciated) which presents a higher level interface when compared to FunctionalAffect. In particular, it decouples the inputs and outputs to the affect from the precise problem structure post-simplification.

This isn't quite complete yet; I need to implement it marking unknowns mutating by affects irreducible so that they're always there come runtime. Close, however.

[BenChung]

I'm increasingly happy with this implementation; the main caveat to that statement is that the use of ComponentArrays for MutatingFunctionalAffects means that the values passed in and out are homogenously typed (that is they're all float64s, which is not great).

[AayushSabharwal]

This looks like a rebase gone wrong 😅

[BenChung]

Yep, alas. I'll fix it with a force push

[ChrisRackauckas]

Rebase.

[BenChung]

@ChrisRackauckas In terms of simplification, what'd be your thoughts on how to trim this down in that case?

[ChrisRackauckas]

It's just hard to review because there's multiple things going on here. There's an extension to SymbolicContinuousCallback, there's changing options in build_explicit_observed_function, and there's ImperativeAffect callback. So it's effectively 3 PRs at once. I think the current merge blocker would be the arguments in build_explicit_observed_function vs build_function.

Also, since the ImperativeAffect is marked as experimental, it should all be isolated to a file so that if it's removed it can be done cleanly. It seems like there are utils for ImperativeAffect that are mixed in with the other callbacks?