Drake: Cleanup of trajectories-related source paths

[jwnimmer-tri]

(Per discussion on slack...)

We should clean up the scattered nature of our trajectories-related C++ code. Currently, we have:

• drake/systems/trajectories
• drake/solvers/qpSpline
• drake/solvers/trajectoryOptimization

The strong consensus was that:

• (1) these should all move to the same subdirectory (or siblings of a common parent) -- which is captured in this issue;
  
  
  
  • (a) the drake/systems/trajectories and drake/solvers/trajectoryOptimization files should go directly into the new home (no separate subdirs);
  
  
  • (b) the drake/solvers/qpSpline files should probably stay partitioned as a subdirectory of the new home, in case we want to refactor or ditch them as a group;
  
  
• (2) there should be a TrajectorySystem<T> source in systems/framework/primitives that takes a trajectory object and produces the trajectory on a system output port -- which is a separate issue. _Edit: This already exists, as systems/framework/primitives/trajectory_source_.

The proposal for the new home is drake/common/trajectories. That yields a dependency graph of common/trajectories -> solvers -> math -> common (because trajectories uses MathematicalProgram). That's not technically circular (CMake and Bazel are both (I think) okay with it), but in my dream world the top-level dirs are 100% layered with no back-references. Perhaps we live with it for now.

When we move these files, we'll also take care of the #1965 renames on them.

[jwnimmer-tri]

/CC @siyuanfeng-tri @manuelli @sammy-tri @Lucy-tri

[manuelli]

I am a little late to the discussion but I tend to agree with Siyuan that the trajectories are just simple utilities. I have never used qpSpline, and I don't think it is currently used in anything we do on the robot. I guess I am unclear on the logic behind putting drake/solvers/trajectoryOptimization in the same place as trajectories. One is really an optimization, the other is just a container for a trajectory (piecewise linear, cubic spline etc.). On the other hand I don't have particularly strong views on it either.

[RussTedrake]

I'm sorry... i was unclear on slack. I think that trajectoryOptimization still belongs under solvers. I think that qpSpline does not.

[jwnimmer-tri]

Oh, I like that better also. So I think the proposal is now:

• drake/systems/trajectories renames to drake/common/trajectories.
  
  
  
  • This rename breaks the weird systems-vs-solvers loop.
  
  
  • The new directory contains only datatypes (representations of trajectories) and possibly factory methods for creating them (e.g., a bunch of Eigen code to do some math); it specifically may _not_ call the solvers stack.
  
  
• drake/solvers/qpSpline renames to drake/common/trajectories/qp_spline and gains a README.md saying that we should consider refactoring it, dropping it, or something.
• drake/solvers/trajectoryOptimization renames to drake/solvers/trajectory_optimization per cppguide, but otherwise remains intact.