Support for multiple meshes in a single obj file

[jwnimmer-tri]

In some cases (e.g., some kinds of collision queries), Drake requires that a user decompose their non-convex mesh geometry into convex pieces. Some third-party tools for doing that create their output as a single *.obj file that contains multiple meshes. When the user tries to load that into Drake, they see this error:

RuntimeError: The OBJ file contains multiple objects; only OBJs with a single object are supported.

The work-around would be to break into one file per mesh and update the SDFormat (or etc.) file to add multiple geometries, but it would be much more convenient if we could stick with the single OBJ file.

[jwnimmer-tri]

One question worth checking: do meshlab, rviz, drake_visualizer support multi-mesh input format? If they don't, we might need to be careful how we resolve this.

[SeanCurtis-TRI]

See #20185 for the bulleted list that is resolving this issue.

[SeanCurtis-TRI]

Clarification -- the error message above comes when the mesh is assign proximity properties. This has never been a problem for illustration properties and the PR train represented by #20235 will resolve it for our render engines. So, proximity is all that remains.

This is only relevant when the ReadObjFile() method is called. So, with that in mind, here's the circumstances in which it is relevant:

1. In geometry/optimization/vpolytope
   • Creates a convex hull of the mesh's vertices. This application could safely not care about how many "objects" there are. It just wants the set of all vertices in the mesh. If the error went away, vpolytope would only benefit.
   • This would easily be resolved by a flag to the ReadObjFile() method that indicated whether it cared about the number of objects. This usage could simply opt out.
2. ProximityEngine
   • Convex shape reification
     • If the multiple partitioning were actually a partitioning of a legitimate convex mesh, we could simply consider the union and proceed.
     • If the resulting mesh is multiple disjoint meshes, or non-convex meshes, this would be a reason to throw.
     • This will only be meaningfully resolved when we validate the Convex mesh.
     • For now, this error condition is protecting objs declared as Convex. Leaving the error in place here would still be advisable until we can make a more thorough inspection of the result.
   • Mesh shape reification
     • This shouldn't care about the number of objects.
       • For point contact we use a convex hull of the mesh's vertices as a representation (and the hull works fine, even if it spans multiple objects).
       • For hydroleastic, we only support rigid meshes which don't have to be convex, single, or even closed.
       • Again, an opt-out flag would unblock this as well.

[SeanCurtis-TRI]

Closed by #21745