[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

There is some apparent low-hanging fruit to be exploited:

• [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)
• [ ] Combine Mobilizer & BodyNode into a single class (e.g. MobilizedBody) with templatized implementations permitting common operations to be performed with only a single virtual function call. The executed code should use only fixed-size matrices (currently there is a lot of MatrixUpTo6 fluff).
• [ ] MultibodyKernel APIs will only allow building a very specific model, with the pre-specified frames above for faster computations, and will only allow building trees (that is, kernel defines the tree in terms of mobilized bodies and therefore the parent mobilized body must have already been added to the model)
• [ ] 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.
• [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.
• [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.
• [ ] For tree-sweeping algorithms, 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.
• [ ] 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.
• [ ] Move template function definitions into .cc files and explicitly instantiate there to improve compile times.

Performance work should be backed by timings taken on the same computers. Cassie bench's mass matrix, inverse dynamics, and forward dynamics make good targets.

[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: