Add an odometry term in 2D/3D modeled after 2D's consecutive scan term

[damonkohler]

In 2D, since we don't tie poses together with IMU reading, we tie poses together by position. That is, from one pose to the next, the position shouldn't change drastically without sufficient evidence.

The same approach could be used to integrate odometry information. That is, relative odometry readings from one position to the next should not be violated without sufficient evidence.

[BrannonKing]

It sounds like this is the same bug as #242 and #467 and cartographer-project/cartographer_ros#488, or that they have all morphed together as PoseExtrapolator has taken over the odometry->velocity role. PoseExtrapolator::AddImuData is just too sensitive to noise in the odometry data. Most odometry data comes from wheel encoders; they slip and they often aren't regularly periodic. There is some noisy calculus to convert from multiple wheel encoders into a single odometry point. Simulating them (from my experience) isn't noise-free either -- the timing in the simulation tools is lousy.

[SirVer]

@cschuet @wohe Is this fixed with your recent 2D/3D unification?

[cschuet]

Fixed in #570.