Visualized proximity geometry should be partitioned into categories denoting origin

[SeanCurtis-TRI]

Problem statement

The geometry used for proximity query can come from a number of sources:

• Literal mesh declared in a model (e.g., Box, Sphere, Mesh)
• Convex hull derived from Mesh or Convex.
• Hydroelastic tessellations of primitives.

Currently, they all appear the same when proximity geometry is added to meshcat.

Proposal

We should allow the user to more easily distinguish the origin of the geometry. Possible mechanisms:

• Color scheme where each category is given a distinct color.
  • When applying a color scheme, should it always win? Or should we let per-geometry colors be used?
  • How would this be reconciled when an obj with materials is used? Which color wins?
• Grouping in the drake/proximity path as drake/proximity/hydro, drake/proximityi/convex_hull, etc.

[jwnimmer-tri]

See also #20171.

[jwnimmer-tri]

The "Problem statement" above is a survey of existing conditions, not a statement of something that is painful or undesirable. It would help sharpen up this ticket if we could more clearly express what problem / pain point needs solving.

I imagine something along the lines of "a user is creating a scene using DMD files and ..." then ends up in a pile of confusion due to confusing or insufficient default visualization capabilities. Having a more clear story there would help us figure out what kinds of solutions to consider, and their relative merit.