Improved FunctionalAffect alternative

[BenChung]

Checklist

• 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.
• 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.

[ChrisRackauckas]

I'm not super happy with the implementation, I think it seems a bit more complicated than maybe it could be, but I'm willing to see how this goes because it's marked as experimental

[baggepinnen]

If I pass StaticVector{Float64, 3} here, I still get a Vector right? Seems slightly confusing, although the docstring is rather clear on what options are available.

There is an option to get static arrays out from build_function, would it make sense to follow this same interface for build_explicit_observed_function?
https://github.com/JuliaSymbolics/Symbolics.jl/blob/10a61ee505038f4faaf9e1edbcda1caeed8d4cc7/src/build_function.jl#L285

[ChrisRackauckas]

Yes it would make sense to do the same thing here.

[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?

[baggepinnen]

Suggested change

	(cb, fn) -> begin
	function (cb, fn)

anonymous functions can be written this way as well, which maybe looks slightly nicer

[AayushSabharwal]

Just a minor doc thing I found