Expand kinematics introduction with why/when guidance

[jasondaming]

Summary

Significantly expands the kinematics introduction article to address issue #1291 by explaining why teams should use kinematics/odometry and when to choose each drivetrain type.

Changes

New "Why use kinematics and odometry?" Section

• Enhanced Autonomous Performance: Explains accurate path following, position tracking, and self-correction with vision
• Field-Oriented Control: Describes benefits for holonomic drives and driver experience
• Trajectory Generation and Following: Integration with path planning tools
• Common Use Cases: Real-world examples of autonomous routines, vision-assisted driving, teleoperation enhancement

New "When to use each drivetrain type" Section

Differential Drive:

• Best for: Traditional tank drive, high traction/pushing power, simpler builds
• Characteristics: Non-holonomic, high pushing power, simpler mechanical design
• Links to RamseteCommand example

Swerve Drive:

• Best for: Maximum maneuverability, competitive teams with experience
• Characteristics: Holonomic, highest mobility, most complex
• Links to SwerveBot and SwerveControllerCommand examples

Mecanum Drive:

• Best for: Holonomic drive with simpler mechanics than swerve
• Characteristics: Can strafe, lower pushing power, simpler than swerve
• Links to MecanumBot and MecanumControllerCommand examples

Important Considerations

• Odometry drift and vision-based corrections
• Sensor requirements for each drivetrain
• Autonomous period accuracy expectations
• Coordinate system reference

Impact

This expansion transforms the article from a purely technical reference into a practical guide that helps teams:

1. Understand the benefits of using kinematics and odometry
2. Choose the appropriate drivetrain type for their needs
3. Know what sensors and setup are required
4. Find relevant example code for their chosen drivetrain

Fixes #1291

[katzuv]

Suggested change

	**Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy.
	**Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots and field elements. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy.

[katzuv]

Suggested change

	**Autonomous period accuracy**: Odometry is typically very accurate during autonomous (15 seconds) because there's less robot-to-robot contact. Estimates may drift more during teleoperation.
	**Autonomous period accuracy**: Odometry is typically very accurate during autonomous (15 seconds) because there's less robot-to-robot contact. Estimates may drift more during teleop.

Using language from the manual. TELEOP is in the glossary for "the Teleoperated Period".

[katzuv]

Perhaps the comparison between different drivetrain types fits more elsewhere?