Unify naming: rename .vars → .variables across Constraint/LinearExpression/QuadraticExpression

[FBumann]

Today the read-side uses vars but the typed mutation API uses variables:

• Constraint.vars (property + deprecated setter)
• Constraint.update(variables=...) (kwarg)
• Same split on LinearExpression.vars, QuadraticExpression.vars, and the underlying Dataset key

The kwarg was variables to avoid shadowing the vars() builtin in kwarg position — that reasoning doesn't apply to property names. Result is c.vars to read but c.update(variables=...) to mutate, which is mildly confusing.

Proposal

Rename .vars → .variables on Constraint, LinearExpression, QuadraticExpression, and the underlying Dataset key. Keep .vars as a deprecated alias for one release cycle, then remove.

Scope / cost

• Touches every internal callsite + the Dataset key.
• PyPSA reads c.vars directly in many places — needs coordination.
• Two-release deprecation: add .variables, alias .vars with DeprecationWarning, remove later.

Out of scope for #727 (typed .update() API); tracking separately.

[FabianHofmann]

I agree! would give this low prio for now

[FBumann]

Yes, will create conflicts...

[FBumann]

Closing — on reflection the rename trades a small asymmetry (c.vars read vs. c.update(variables=...) mutate) for a worse one (Python property .variables ≠ underlying xarray Dataset key "vars"). The Dataset key can't cleanly become "variables" either, since xarray.Dataset.variables is a built-in attribute that would shadow it (forcing data["variables"] and breaking the uniform data.coeffs/data.const/data.vars access pattern). If the original asymmetry is worth fixing, the cheaper move is renaming the update(variables=) kwarg back to vars=.