[multibody] Remove duplicated free body APIs

[xuchenhan-tri]

MultibodyPlant has a list of "free body" APIs that used to be the preferred way to interact with free bodies. This has changed since #18390 introduced a floating joint between world and all free bodies. With that, we should interact with free bodies using the associated joint's API as we do with all other MultibodyPlant degrees of freedom because the dual body/joint representation can be error prone (e.g. #19106 fixed by #19230). Instead, MultibodyPlant can provide sugar that retrieves the floating joint associated with the body if it is indeed floating.

This idea originated from a discussion in #19230. cc @jwnimmer-tri @sherm1 @joemasterjohn

[jwnimmer-tri]

To expand a little bit -- there are lot of functions available for joints, e.g., configuring locking, damping, limits, etc. At the moment, only a fraction of those appear in the MbP's "free body" APIs section. Rather than offer an incomplete subset of the Joint functions on MbP directly, we should separate the concerns. MbP should be able to give the user the Joint associated with a free body, and then the user can call any and all Joint functions directly.

While doing this porting if we find that there is a very common use case where the two function calls instead of one makes a big difference, we can consider keeping the extra sugar. The nominal choice, though, should be to deprecate and remove all of the extra functions, unless there is a specific reason why not.

[SeanCurtis-TRI]

Be careful with use of the word "floating". RigidBody::is_floating() does not mean has a floating joint in-board. It means has a floating joint in board and the parent body is world. This excludes those bodies for whom world is not the parent body, but nevertheless have 6-dof poses to set.

[sherm1]

I'll take a look at cleaning up this API.

Sean's documentation PR #21802 improved things a bit. The terminology is now clearer:

• a "free" body is one that has 6dofs w.r.t. its parent
• a "floating base" body is a free body whose parent is World.

The API doesn't perfectly match right now. We have "floating" joints that should be called "free" joints. We have APIs with "Free" in the names that work only on floating base bodies. is_floating() should be is_floating_base(), etc. My initial thought is that some operations on floating base bodies are worth preserving because they are particularly natural for manipulands where there is just a lone body. But I don't see the utility in extending that to free bodies with non-World parentage since there is always an explicit joint there. OTOH we ought to treat bodies welded to World as indistinguishable from World for the definition of a floating base. More later.