Support `sympy.physics.mechanics.dynamicsymbols` as well as `sympy.Symbol` in SymPy backend

[brocksam]

The SymPy backend should natively support sympy.physics.mechanics.dynamicsymbols as well as sympy.Symbol objects (as was the case prior to 24eb461). It is common for users to use sympy.physics.mechanics to derive equations of motion (EoMs) that are then used to construct their optimal control problem. These EoMs will be built from both sympy.physics.mechanics.dynamicsymbols and sympy.Symbol objects. It should be possible to directly set sympy.physics.mechanics.dynamicsymbols as state and control variables in the OCP definition when the SymPy backend is being used to save users doing a replacement to sympy.Symbol objects, which can be costly for large and complex models.

Note: the workaround until this issue is resolved is for users to manually substitute sympy.Symbol objects in place of sympy.physics.mechanics.dynamicsymbols before constructing their OCP via pycollo.OptimalControlProblem.

[brocksam]

PR #67 has implemented the basics of this in a way that'll work with the CasADi backend. See the PR description for details about how it can be used. Particularly if you wish to access the state variables from Phase.state_variables as attributes using the symbol's name, the (t) of the me.dynamicsymbol is trimmed off. I.e. using me.dynamicsymbols("x") with name x(t) can be accessed by phase.state_variables.x.

[brocksam]

Currently it's not possible to use Derivative(x(t), t) as state or control variables without error.