Remove use of XXX in comments (RobotLocomotion#13341)

Programmers conventionally use "Foo" as the stand-in name.

multibody/plant/multibody_plant.h

@@ -964,7 +964,7 @@ class MultibodyPlant : public internal::MultibodyTreeSystem<T> {
   ///
   /// <h4>Geometry registration with roles</h4>
   ///
-  /// Geometries can be associated with bodies via the `RegisterXXXGeometry`
+  /// Geometries can be associated with bodies via the `RegisterFooGeometry`
   /// family of methods. In SceneGraph, geometries have @ref geometry_roles
   /// "roles". The `RegisterCollisionGeometry()` methods register geometry with
   /// SceneGraph and assign it the proximity role. The

multibody/tree/force_element.h

@@ -95,7 +95,7 @@ class ForceElement : public
   /// for CalcPotentialEnergy() for a detailed description of the input
   /// arguments of the methods in this group.
   ///
-  // TODO(amcastro-tri): make this methods DoCalcXXX() when caching gets in and
+  // TODO(amcastro-tri): make this methods DoCalcFoo() when caching gets in and
   // make the public API's to only take a Context.
   //@{
 

multibody/tree/multibody_tree.h

@@ -1402,7 +1402,7 @@ class MultibodyTree {
   /// compute kinematics, forward and inverse dynamics, and Jacobian matrices,
   /// among others.
   /// These methods follow Drake's naming scheme for methods performing a
-  /// computation and therefore are named `CalcXXX()`, where `XXX` corresponds
+  /// computation and therefore are named `CalcFoo()`, where `Foo` corresponds
   /// to the quantity or object of interest to be computed. They all take a
   /// `systems::Context` as an input argument storing the state of the multibody
   /// system.

multibody/tree/uniform_gravity_field_element.cc

@@ -83,7 +83,7 @@ void UniformGravityFieldElement<T>::DoCalcAndAddForceContribution(
     const Body<T>& body = model.get_body(body_index);
     internal::BodyNodeIndex node_index = body.node_index();
 
-    // TODO(amcastro-tri): Replace this CalcXXX() calls by GetXXX() calls once
+    // TODO(amcastro-tri): Replace this CalcFoo() calls by GetFoo() calls once
     // caching is in place.
     const T mass = body.get_mass(context);
     const Vector3<T> p_BoBcm_B = body.CalcCenterOfMassInBodyFrame(context);
@@ -110,7 +110,7 @@ T UniformGravityFieldElement<T>::CalcPotentialEnergy(
   for (BodyIndex body_index(1); body_index < num_bodies; ++body_index) {
     const Body<T>& body = model.get_body(body_index);
 
-    // TODO(amcastro-tri): Replace this CalcXXX() calls by GetXXX() calls once
+    // TODO(amcastro-tri): Replace this CalcFoo() calls by GetFoo() calls once
     // caching is in place.
     const T mass = body.get_mass(context);
     const Vector3<T> p_BoBcm_B = body.CalcCenterOfMassInBodyFrame(context);
@@ -140,7 +140,7 @@ T UniformGravityFieldElement<T>::CalcConservativePower(
   for (BodyIndex body_index(1); body_index < num_bodies; ++body_index) {
     const Body<T>& body = model.get_body(body_index);
 
-    // TODO(amcastro-tri): Replace this CalcXXX() calls by GetXXX() calls once
+    // TODO(amcastro-tri): Replace this CalcFoo() calls by GetFoo() calls once
     // caching is in place.
     const T mass = body.get_mass(context);
     const Vector3<T> p_BoBcm_B = body.CalcCenterOfMassInBodyFrame(context);

tutorials/mathematical_program.ipynb

@@ -466,7 +466,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Each solver has its own details. You should refer to `XXXSolverDetails` class on what is stored inside the return argument of `result.get_solver_details()`. For example, if you know that IPOPT is called, then refer to `IpoptSolverDetails` class; for OSQP solver, refer to `OsqpSolverDetails`, etc.\n",
+    "Each solver has its own details. You should refer to `FooSolverDetails` class on what is stored inside the return argument of `result.get_solver_details()`. For example, if you know that IPOPT is called, then refer to `IpoptSolverDetails` class; for OSQP solver, refer to `OsqpSolverDetails`, etc.\n",
     "\n",
     "### Using an initial guess\n",
     "Some optimization problems, such as nonlinear optimization, require an initial guess. Other types of problems, such as quadratic programming, mixed-integer optimization, etc,  can be solved faster if a good initial guess is provided. The user could provide an initial guess as an input argument in `Solve` function. If no initial guess is provided, Drake will use a zero-valued vector as the initial guess.\n",