Add support for generic (nonlinear) ExpressionCost

[jwnimmer-tri]

Is your feature request related to a problem? Please describe.

We currently offer a generic MathematicalProgram::AddConstraint(Expression, lb, ub) function that's useful for prototyping:

https://github.com/RobotLocomotion/drake/blob/7233a94a7eb96306422f75cd2f12d426a57a9160/solvers/mathematical_program.h#L1280-L1287

The user can pass any symbolic expression -- if it's of a functional form that we can easily recognize and handle efficiently, we parse it into that form (e.g, a Binding<LinearConstraint>). If we can't parse it, we fall back to a Binding<ExpressionConstraint> that uses Expression::Evaluate and symbolic::Jacobian to evaluate the constraint.

We also have an analogous MathematicalProgram::AddCost(Expression) function:

https://github.com/RobotLocomotion/drake/blob/7233a94a7eb96306422f75cd2f12d426a57a9160/solvers/mathematical_program.h#L1165-L1171

It has the same flavor, but has a much stronger pre-condition -- only linear or quadratic costs are supported. If the user passes a non-linear cost, they get an exception about "Expression ... is not polynomial ...".

This is inconsistent and confusing.

Describe the solution you'd like

This AddCost overload should only throw when the cost is trivial (i.e., a constant like "5").

This probably means adding an ExpressionCost class as the most generic fallback.

[sherm1]

Assigned to Hongkai for disposition.

[RussTedrake]

FWIW - a few students have hit this, so I'm implementing it now. Re: "should only throw when the cost is trivial (i.e., a constant like "5")." -- I would argue that constant costs should be allowed here, too.