[multibody] MultibodyTree performance improvement epic

[sherm1]

Per discussion with @amcastro-tri, we would like to perform some major surgery on MultibodyTree to achieve these goals:

• Make it produce the same results as fast as possible, with 10X as a target (primary goal)
• Clean up the code with an eye to making some of its API public
• Fully decouple the numerical algorithms from non-numerical aspects of System and Context, and encapsulate the numerics in a MultibodyKernel.
• Substantially reduce compile time

Here are the planned tasks:

• [x] Move tree-building computation from multibody_tree_topology to multibody/topology so the calculation is performed by MbP as an instruction to MbT on how to build the model. Future upgrades to multibody_graph will support kinematic loops and allow API exposure of both the link/joint input structure and the body/mobilizer/constraint structure of the model. (done, see #20225)
• [x] MultibodyPlant uses the new graphing and forest code, done in #21820
• [x] Combine Body and RigidBody to eliminate a layer of virtual function calls required to access mass properties. Ideally rename the combined class "Link" and deprecate the old names. Eliminate other vestiges of non-rigid Body types since we handle deformation differently now. PR #20676
• [x] Fix the Frame, BodyFrame, FixedOffsetFrame classes so that we can use references to their poses rather than copies. Redefine Frame to mean frame fixed on a rigid body, templatize to indicate whether there is an offset from body frame, consider special casing translation-only offset. PR #21853
• [ ] Templatize BodyNodeImpl by concrete Mobilizer type with templatized implementations permitting common per-mobod operations to be performed with only a single virtual function call. WIP #21862
• [ ] The executed code for tree-sweeping algorithms should use only fixed-size matrices (currently there is a lot of MatrixUpTo6 fluff), and should find the q and v data in the Context once at the start and then pass the raw data to each mobilized body operation in the MultibodyKernel rather than passing in the Context for repeated spelunking . PR #21862 does this for kinematics; finish the rest of the algorithms.
• [ ] MultibodyKernel APIs will only allow building a very specific model, on specific frames chosen to minimize FLOPS, and will only allow building trees.
• [ ] Logically separate the "kernel" (numeric) code from the higher-level context and system framework-using code.
• [ ] Provide MobilizedBody specializations that provide optimal handling of (a) revolute, (b) prismatic, and (c) free joints that have simple H matrices after the above processing. Example: calculating X_FM for a prismatic joint should not require writing anything but the translation.
• [ ] Reparameterize MbTree to work with frames chosen for efficiency. In general this means the effective body origins will be moved to the inboard joint frame (Bo==Mo) and aligned so that the H matrices for common joints have only a single non-zero element. (This would be hidden from users who would only see things through MultibodyPlant in their original frames.) An alternative would be to compute a principal-axes frame so that the COM offset is zero and inertias diagonal.
• [ ] Investigate using specialized rotation and transform operations for revolute and prismatic mobilizers (see Alejandro's kernel prototype).
• [ ] Investigate using specialized "update" operations rather than "calc" operations for transforms and spatial vector results since most mobilizer types need only touch a subset of the elements.
• [ ] Move template function definitions into .cc files and explicitly instantiate there to improve compile times.
• [ ] Consider whether the above modifications to the existing kernel code are sufficient, or whether we need to develop a new "second generation" kernel along the lines of Alejandro's prototype (see this branch).

Performance work should be backed by timings taken on the same computers. Cassie bench's kinematics, mass matrix, inverse dynamics, and forward dynamics make good targets. See PR #21862 benchmark table for an example.

[sherm1]

[Capturing a 1:1 discussion w/Alejandro]

Thoughts on how to present multibody modeling elegantly

1. User defines Plant structure via Links and Joints, producing a directed (parent->child) graph, plus some disconnected Links. Call this LinkJointGraph.
2. At Finalize() (or any other time by request) we produce a forest-of-spanning-trees model of the LinkJointGraph, with depth-first coordinate assignments. Call this SpanningForestModel (or some better name). Should have an API for forest info.
3. Augment the Plant structure with additional elements (added free Joints, shadow Links, added constraints) to use as a uniform interface to those elements for users who care (we already do this with floating Joints). The augmented elements are easily removed when we remodel.
4. Use MultibodyKernel for the tight, efficient Featherstone-ish thing that only takes basic numerical data structures and computes kinematics, inverse/forward dynamics, etc. Figure out how to make that public
   • no context!
   • no systems::

Both LinkJointGraph and SpanningForestModel have nice public APIs for users to query.

MultibodyTree should then be thought of more like MultibodyPlantImpl (consider renaming). Its job is to implement an efficient computational representation of the SpanningForest (which essentially replaces the MultibodyTopology stuff), creating a MultibodyKernel devoted entirely to fast computation.

Here is a sketch of a LinkJointGraph with a loop being modeled as a spanning tree and an augmented LinkJointGraph: