use `AddConstraint(symbolic::Formula)` to handle all types of constraints

[hongkai-dai]

Goal

Currently we support

AddLinearCost(symbolic::Expression);
AddQuadraticCost(symbolic::Expression);
AddLinearConstraint(symbolic::Formula); // linear equality constraint, linear inequality constraint, bounding box constraint
AddLorentzConeConstraint(symbolic::Expression e);
AddRotatedLorentzConeConstraint(symbolic::Expression e);
AddPositiveSemidefiniteConstraint(Eigen::Matrix<symbolic::Expression, Dynamic, Dynamic>);

We want to use AddCost(symbolic::Expression) and AddConstraint(symbolic::Formula) to handle all of these different forms, namely all costs and constraints in the supported convex optimization.

Approach

We will handle constraints and costs separately.

1. For cost, add a method

   AddCost(const symbolic::Expression& e)

   To handle both linear and quadratic cost, throw a runtime error if the input is not a linear or quadratic expression.
   Question: what is the return type for this function? I think Binding<Constraint> can work, but we lost information specific to the derived class like LinearConstraint and QuadraticConstraint.

2. For constraint, add a method

   AddConstraint(const symbolic::Formula& e)

   Question: What is a good way to write a conic constraint, such as Lorentz cone or semidefinite matrix cone? Shall we create a type of symbolic::Formula for A*x+b is in K, where K is a type of the cone?

[hongkai-dai]

@soonho-tri and @RussTedrake for discussion.

[RussTedrake]

I agree with all of the above. My sense is that this is very similar to what is happening in AddLinearConstraint right now. I agree that we will be throwing away return type information, but if the caller is being non-specific with the call, then presumably it will be ok being non-specific with the return type, too.

[hongkai-dai]

Agree, I will first work on AddCost(symbolic::Expression) to handle both linear and quadratic costs.