`Symbolics.build_funciton` now supports common-subexpression elimination

[baggepinnen]

build_function(...; cse=true) can now yield enormous speedups, the simple benchmark here went from 2.490 μs to 184.236 ns for a sparse Hessian. It would be nice if this was activated in DI.

@AayushSabharwal are there any cons to enabling it by default?

[AayushSabharwal]

It should just work. There aren't any downsides besides readability that I'm aware of, but it would be good to run Symbolics CI with the flag toggled to be certain.

[baggepinnen]

I was primarily asking about using cse=true as default in DI.jl, but having it default to true in Symbolics directly is of course also an option

[AayushSabharwal]

The reason I want to run CI is not to toggle the flag (I'd argue that that's breaking) but because running downstream CI with the flag toggled will tell us what side effects there are, if any.

[gdalle]

If toggling the flag is breaking for Symbolics, I'd argue it would be breaking for DI too?
Perhaps a better option would be to add a setting to ADTypes.AutoSymbolics and leave it off by default, but allow users to turn it on.

[baggepinnen]

It's breaking in a very strict interpretation of the word, e.g., it does not break the documented behavior, instead, results might be numerically subtly different due to different rounding, and any use of impure functions would yield a different result, but such use of Symbolics for AD is undefined behavior anyway so I would not waste any cycles on that. @AayushSabharwal do you think there could be any sound and reasonable use of AutoSymbolics that does not rely on bit for bit identical results, that could be broken by CSE?

For example, the tests DI has for AutoSymbolics should still pass, and if they do, the change is okay up to the test accuracy of this package.

[AayushSabharwal]

Nope, for DI it should be fine

[gdalle]

Do you want to open a PR? Should cse be activated all the time, or just in sparse Jacobians and Hessians?

[baggepinnen]

#759