Joints need an API that more directly support quaternions

[SeanCurtis-TRI]

Is your feature request related to a problem? Please describe.
Related to issue #21215 and PR #21308.

Essentially, we have usages that care about distinguishing between joints that have quaternions in their state space and those that don't. As of the time this issue submission, there is really only one joint that has a quaternion: QuaternionFloatingJoint, but we expect to add BallQuaternionJoint (or some such thing). As of #21308, the code in linear_distance_and_interpolation_and_provider.cc is doing some runtime type checking to determine if the joint has a quaternion. This is brittle. Whoever adds a new joint with a quaternion would have to know about that runtime type checking and accommodate this particular use case, otherwise these joints will not be handled correctly.

Describe the solution you'd like
The proper solution is to define an API on the Joint class that derived classes have to directly handle and then for Drake code (like the example indicated above) to use the virtual methods instead of doing its own type checking. It has the benefit of automatically accommodating new classes that implement the interface and authors of joints don't have to hunting for possible uses of the joint outside of its virtual interface.

Describe alternatives you've considered
As described as "Option 3": #21308 (comment). (reproduced here because it's worth it not getting lost):

The MbP exposes the quaternion norm constraint as a SystemConstraint, and places like CollisionChecker (and elsewhere) that need to know about constraints like that use the SystemConstraint language to interrogate the plant for specifics. This removes the need to loop over joints, and instead uses the fully generic constraint language we already have in place, which can then flex to cases more complicated than unit norm (e.g., mimic, coupler, etc.).

And, finally, maintain the status quo -- create a shopping list of places to look. Not a good option.

Additional context
Add any other context or screenshots about the feature request here.