Improve default names for automatic floating base joints

[RussTedrake]

See extended discussion in slack.

The choice to use e.g. $world_body1 was made during code review, but this choice did not consider all use cases. People writing optimization problems who reference the joint positions by names in constraints don't want something that verbose. Python users using namedview can't eat the $ in the name.

Request: the default names should be something more like {"_"*N}{body_name} for the smallest N that works.

Although we don't have proper depreciation, the slack message includes some relevant ideas from @jwnimmer-tri .

Related to #19162.

[sherm1]

I will use the new scheme in the new MbP graph-building code I'm working on for #18442

[sherm1]

Q: if the system consists of four model instances of the same humanoid (say), we'll add floating joints to the torsos. The proposed scheme makes those joints torso, _torso, __torso, and ___torso with no clear mapping between name and model instance. Is that OK? We could instead guarantee to add underscores in order of model instance index -- is that worthwhile?

Edit: no need to disambiguate across model instances; OK to have the same joint names in different instances. See below.

[jwnimmer-tri]

The proposed scheme makes those joints torso, _torso, __torso, and ___torso ...

That's not the proposal (as I understand it). The proposal is to use the model instance name as the basis for the floating joint name. Each humanoid has a unique model instance name. The only de-confliction we need to do is between the implicit floating joint's name, and any other pre-existing joint names within the model. The chance of a joint named humanoid_3 within the humanoid xml seems low.

Edit: Ah, the text above did say body_name, didn't it? That seems wrong. I think it should be model name, for the reasons above.

[sherm1]

A single model instance can include multiple floating bodies -- naming the joints for the bodies as in Russ's proposal seems like the natural approach and least likely to require disambiguation.

[sherm1]

Ah, sorry. I forgot that we can have the same names in multiple model instances. So the only disambiguation we need is if the model contains both a floating body named "xyz" and an unrelated joint named "xyz" in the same model instance (very unlikely!). In that case we would need to make body xyz's joint be "_xyz" to avoid a joint name conflict.

[jwnimmer-tri]

Fair enough. I'm happy to allow whoever implements this to think carefully about the naming choices and back it up with unit tests.