MbP: Decouple "physical" from "modeling" topology representation

[amcastro-tri]

There have been a number of requests from users for introspecting a multibody model. Some of them are purely "physical". For instance, what joints attach to a body, or what bodies form an island of welded bodies, #9754. Others have more to do with the modeling choices the MBP took for the particular system. Typically, when thinking of minimal coordinates, users would like to know what portion of the state belongs to a quaternion, or what body is the "base", #10736, #9747.

We believe those questions can be answer by two different representations of the multibody model:

1. A physical representation consisting of bodies and joints. This representation will consist of a graph (with bodies at the nodes and joints as edges).
2. A modeling representation consisting of mobilized bodies and constraints. This representation will consist of a tree (or forest).

A first draft towards this goal is provided in #10068 which provides the actual code that takes a graph representation and build a modeling representation.

More recently #11257, splits the topology (a graph, not templated on T) of the "physical" representation.

One problem to be discussed/solved is how/if these representations can be offered publicly to users with proper documentation to avoid confusion and hopefully make things easier to instrospect depending on the particular needs of a user.

cc'ing @EricCousineau-TRI, @sherm1

[tri-ltyyu]

Can improve usability and un-clutter the API.

[EricCousineau-TRI]

Attempt to summarize f2f from triage meeting: This issue is focused primarily on providing a separation between physical topology queries and the tree structure.

This issue is not focused on what computational API abstractions / changes may be necessary to abstract different computational models (e.g. minimal vs. maximal coordinates).

[amcastro-tri]

we merged the "physical" representation of the topology, MultibodyGraph, in #11257, enabling topological queries pre-finalize. In this first spiral MultibodyGraph lives in an internal:: namespace. We are considering to make it public.

[amcastro-tri]

We introduced introspection for floating bodies in #11464, which seems to satisfy some of the immediate user requests. Resolving this issue will become high priority when we attempt to have loop joints.

[jwnimmer-tri]

I think we already have better tracking issues related to this, and #20225 on the way.