Make constraints as Model instead of the same as their parent model

[pckroon]

ODEModels make for poor constraints, since they require an initial argument, which is not passed by BaseModel.as_constraint. This does mean that if you want to use an ODEModel as constraint, you need to initialize your constraint model yourself, and pass it.
On top of that, this PR adds initial ODE parameters to the connectivity_mapping.

Fixes #282

[tBuLi]

The constraints are not passed to Fit. It is probably better to use an equatilty or make the constraint the other way around, since initially the constraint is already true so we don't know if it was enforced properly.

[tBuLi]

Nice one. But I think the original reason for using the same class is that when adding constraints to a CallableNumericalModel, the constraint also needs to be of that same type, in case the constraint reuses some of the components of the original model. This functionality is now broken.

E.g.

model = CallableNumericalModel({y: lambda x: a * x**2}, connectivity_mapping={y: {x, a}})
constraint = CallableNumericalModel.as_constraint(
    {z: lambda y: np.sum(y)}, 
    connectivity_mapping={z: {y}}, 
    model=model, constraint_type=Eq
)

I'm actually surprised the tests didn't fail for this, I guess that means I never added proper testing for the above functionality. Perhaps whoever of us has time first can check if this indeed works, because this is very nice functionality to have: it means that also for these kinds of models the constraints can depend on the output of the model, not just the parameters. I personally already used this type of construction to fix the integral of my solution to be 1.

So I think I'm more in favor of adding a simple check for ODEModels and only do your new fix there but keep the standard behavior otherwise.

[tBuLi]

I also think that ultimately the solution would be to rework ODEModel into a subclass of CallableNumericalModel so we can also more easily mix component of ODE and non-ODE type like in the recent issue #284, but might be bigger than the current issue.

[pckroon]

I also think that ultimately the solution would be to rework ODEModel into a subclass of CallableNumericalModel so we can also more easily mix component of ODE and non-ODE type like in the recent issue #284, but might be bigger than the current issue.

I forgot about this TODO. I'll fix both in one go.

[tBuLi]

Btw, a potential unified syntax could be as follows:

ODEModel({
    D(y, t): - k * y,
    y: 1,
    t: 0
})

This would move everything to the model_dict and makes the ambition of having expressions as initial conditions much easier. It would also streamline internal code regarding ODEModels, though at the expense of some readability for the user I think, since it is not immediately obvious that these are to be read as initial conditions. What do you think?

[tBuLi]

It could also be a good idea an improved version of the current ODEModel but call it RawODEModel instead, and then make a new ODEModel which allows for mixing of ODE and normal expressions, but which then seperates the ODE components into a RawODEModel and then adds this as a numerical component to a CallableNumericalModel. This would essentially automate the process here: https://symfit.readthedocs.io/en/stable/examples/ex_CallableNumericalModel_ode.html