docs: Document DAEProblem constructor

[vyudu]

Fix #3485

[cstjean]

If possible, it is recommended to formulate your problem in terms of an ODEProblem

In MTK, this boils down to "avoid algebraic constraints other than a = b equalities and sum-of-flow equations", right?

[vyudu]

sorry, my message is kind of misleading, ODEProblem can be used for systems with arbitrary algebraic equations attached to them, what I mean here is to formulate DAEs in terms of the mass matrix Mu' = f(u, p, t) (for the ODEProblem) rather than the fully implicit form f(u', u, p, t) = 0 (for the DAEProblem) if possible/convenient.

To be honest, I'm not sure if there's any cases where you actually should or need to make a DAEProblem from a MTK system since it seems like ODESystems are naturally in the mass matrix form, so maybe this message should be more explicit along the lines of "You shouldn't ever use DAEProblem". But I'm not sure if this is true. @ChrisRackauckas ?

[ChrisRackauckas]

If possible, it is recommended to formulate your problem in terms of an ODEProblem and use the corresponding ODE Solvers.

MTK does this reformulation, so instead it's that we recommend trying ODEProblem constructor and its solvers first.

To be honest, I'm not sure if there's any cases where you actually should or need to make a DAEProblem from a MTK system since it seems like ODESystems are naturally in the mass matrix form, so maybe this message should be more explicit along the lines of "You shouldn't ever use DAEProblem". But I'm not sure if this is true. @ChrisRackauckas ?

I would put it more as, you should try ODEProblem first.

The case where this might make sense is where there is a naturally non-diagonal mass matrix, since DAEProblem can codegen that and currently ODEProblem cannot do that. But that's currently... the solvers can actually do that, the MTK codegen always goes to a diagonal [111111000] matrix, and that's just a current limitation so I wouldn't embed that into a docstring.