Add ConfigurationToTSRwithTrajectoryConstraint

[gilwoolee]

In preparation for #467, this PR contains the following update:

• Add planner::dart::ConfigurationToTSRwithTrajectoryConstraint
• Add planner::dart::CRRTConfigurationToTSRwithTrajectoryConstraintPlanner
• Add planner_dart component and make relevant changes in CMakeLists files.

The last change is necessary because CRRTConfigurationToTSRwithTrajectoryConstraintPlanner needs to call planner_ompl, which needs to be built before this planner is compiled.

Testing
This PR passes existing unit tests. I'll add unit tests for this planner after the initial review.

---

Before creating a pull request

• Document new methods and classes
• Format code with make format

Before merging a pull request

• Set version target by selecting a milestone on the right side
• Summarize this change in CHANGELOG.md
• Add unit test(s) for this change

[brianhou]

I haven't thought about this very much, but I initially thought it might make sense to add trajectory constraints as a part of all Problems rather than as a specific planner that can deal with them. What do you think? (I guess part of the challenge is that we don't have an reusable component that can plan with those constraints, so I could see an argument that we should just be pragmatic and call this a separate planner type until we do.)

Also, I think it would be good to separate the new planner_dart component into its own PR.

[gilwoolee]

Thanks for the comments @brianhou !
I created another PR #567 as you suggested.

it might make sense to add trajectory constraints as a part of all Problems rather than as a specific planner that can deal with them. What do you think? (I guess part of the challenge is that we don't have an reusable component that can plan with those constraints, so I could see an argument that we should just be pragmatic and call this a separate planner type until we do.)

Yep I agree on both of these. I mainly chose this way for the latter challenge you mentioned and also because this is the only constrained planning problem type we use now. I think it's worth revisiting for a more general solution once we have more of these constrained planning problem types.