Add the ability to pass configuration space obstacles for collision checker

[AlexandreAmice]

In the Iris workflow, we have found it useful to have the notion of convex, configuration space obstacles. We would like all the Iris workflows to use CollisionChecker as a common interface and the notion of configuration space obstacles is also useful in the IrisFromCliqueCovers work. There are essentially two ways to achieve this.

1.) Have CollisionChecker have a member configuration_space_obstacles which are checked for collisions.
2.) Introduce a new class CollisionCheckerWithCspaceCollisionChecker. This class has-a collision-checker checker_ and is-a collision checker. The member checker_ is called for essentially all operations. The only method that is really modified is DoCheckContextConfigCollisionFree. A draft PR of this is available at #21846

Despite the slightly more complicated implementation of option 2, I am in favor of it to avoid CollisionChecker depending on geometry/optimization and avoid adding additional concepts to CollisionChecker which might not be needed by downstream users.

cc @RussTedrake , @Michaelszeng , @wernerpe , @cohnt , @calderpg-tri , @jwnimmer-tri for feedback.

[cohnt]

I understand not wanting to make CollisionChecker depend on geometry/optimization, but option 2 seems like a really gross way to implement this feature.

[jwnimmer-tri]

The only method that is really modified is DoCheckContextConfigCollisionFree.

This particular lemma of the plan is unsound. All public checker functions must be consistent with each other, so at minimum DoCalcContextRobotClearance also needs special handling for the c-space sets.

[calderpg-tri]

What you likely want is something equivalent to the PlanningSpace API we use at TRI. The core design principles of PlanningSpace are:

1. a CollisionChecker is not all you need for planning (e.g. it does not have a sampler)
2. often you have additional ideas of what constitutes state validity (e.g. arbitrary constraints) in addition to collisions
3. there are often task- and problem-specific choices/optimizations useful for planning, and CollisionChecker cannot possibly contain them all

I have been meaning to open a draft PR like #21561 to add a dev directory with a copy of our PlanningSpace API and related planners, from which these can be matured into drake/planning proper.