Move MetaSkeleton-dependent problems to aikido::planner::dart.

[brianhou]

Some problem types are associated with a MetaSkeleton (ConfigurationToTSR, ConfigurationToEndEffector[Offset|Pose]). However, the MetaSkeleton that we use to solve those problems can't be stored in the problem itself because we currently take Problems as const.

@jslee02 and I decided that it would make sense for Planners that solve these problems to take in a non-const MetaSkeleton in the constructor. This PR introduces the aikido::planner::dart namespace for these problem types.

In a future PR, we should add corresponding SingleProblemPlanners for these problems. It would also be useful to have an aikido::planner::dart::ConfigurationToConfigurationPlanner that takes in a non-const MetaSkeleton in its constructor so that we can adapt them more easily.

---

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

[codecov]

Codecov Report

Merging #432 into master will increase coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #432      +/-   ##
==========================================
+ Coverage   80.02%   80.03%   +0.01%     
==========================================
  Files         235      235              
  Lines        6002     6002              
==========================================
+ Hits         4803     4804       +1     
+ Misses       1199     1198       -1

Impacted Files	Coverage Δ
...do/planner/dart/ConfigurationToEndEffectorPose.hpp	0% <ø> (ø)
...orFieldConfigurationToEndEffectorOffsetPlanner.cpp	68.42% <ø> (ø)	⬆️
...r/vectorfield/MoveEndEffectorOffsetVectorField.cpp	74.28% <ø> (ø)	⬆️
...r/dart/ConfigurationToEndEffectorOffsetPlanner.hpp	100% <ø> (ø)
.../planner/dart/ConfigurationToEndEffectorOffset.cpp	73.68% <ø> (ø)
...do/planner/vectorfield/BodyNodePoseVectorField.hpp	100% <ø> (ø)	⬆️
.../planner/dart/ConfigurationToEndEffectorOffset.hpp	100% <ø> (ø)
...r/dart/ConfigurationToEndEffectorOffsetPlanner.cpp	100% <ø> (ø)
...rc/planner/dart/ConfigurationToEndEffectorPose.cpp	0% <ø> (ø)
include/aikido/planner/dart/ConfigurationToTSR.hpp	0% <ø> (ø)
... and 5 more

[sniyaz]

Not really a review thing but more a question from somebody who doesn't know C++ as well- what is the purpose of adding :: here?

[jslee02]

The leading :: is used to represent the following namespace is a top-level namespace. We use this when there is the same name namespace in the "active" namespace. In our case, we use it to distinguish ::dart (i.e., the DART's top-level namespace) and ::aikido::statespace::dart/::aikido::planner::dart.

[sniyaz]

This personally looks good to me 👍

[jslee02]

I believe we only make a new sub-component when it requires optional 3rd-party dependencies. For example, other dart subdirectories of statespace and constraint are not components but included its parent components.

In this sense, I think aikido_planner_ompl and aikido_planner_vectorfield also shouldn't be sub-components.