Add a `constrain(model, x=>(lower=0.1, upper=1))` operation to models

[yebai]

Similar to fix, condition, it is useful to have a constrain method for models to programatically set parameter constraints.

Some common constraints are:

• constrain(model, x=>(;lower=0.1, upper=1))
• constrain(model, x=>UnitSimplex(dim=3))
• constrain(model, x=>PDMat(dim=3))
• constrain(model, x=>Cholesky(dim=3))

[mhauru]

I like this. This could also be an alternative to providing the structure of the model parameters in the first model argument as in #965 and the @of macro. If we made the constraint be a function, it could even handle dynamic models, e.g.

@model function f()
    a ~ Poisson(10)
    b ~ MvNormal(zeros(a+1), I)
end

constrain(model, @varname(b) => pars -> Vector{Float64}(undef, pars[@varname(a)] + 1))

We could also implement the default fixing of parameter types by, at model creation (e.g. when f() is called above) executing the model once, and then calling something like

for vn in keys(vi)
    constrain(model, vn => _ -> typeof(vi[vn])
end

i.e. saying we constrain the values of each variable to be of the same type as they were in that first execution. (I'm being loose here on whether the return value of the pars -> blahblah function is a type or an object, but that's details that can be figured out.) If this does not hold, e.g. for a dynamic model, the user should then call constrain manually to tell us about it. They would only need to do so for the affected variables, and can still rely on the automatic "inference" we do for other variables. So for instance in the first code block of this comment, it's enough for the user to call constrain on b, our automatic constraining mechanism can handle a just fine.

Wit this we could assume that all variables have been constrained, and can make an immutable, simple, and fast VarInfo object for the model.