CameraMapper needs design clarity

There does not appear to be a coherent design of the various obs_* CameraMappers, nor is there a mechanism for documenting or managing the different components of a dataId that each Mapper may require. Something like a TechNote or functionality flowchart would be very helpful when debugging problems, and would provide more uniformity of behavior between the different obs_* packages.

As an example, attempting to use butler.get() on different obs_ repositories can result in various confusing errors depending on the obs_* package, because each obs_* package has different implicit assumptions about the contents of a dataId dictionary. For example, lsstSim currently requires "raft" and "sensor" because of _computeCcdExposureId and getDataId, but this is not obvious to a user of an lsstSim repository. A couple of possible solutions to this problem:

1. Every dataId passed to a camera is validated, including whether it contains all components required by that Camera, with an explanatory exception raised immediately if the dataId is missing a required component.
2. We perform a post-validation step (and don't check for missing components) that fills in the "missing" components based on the contents of the current repository and the passed-in dataId.

I've "relates to" linked a bunch of tickets that seem related to this topic, but I feel there need to be several CameraMapper Epics that define a plan for how we will redesign and rework the Mappers. Maybe this is part of DM-6333, but I feel my specific use case above exemplifies the broader problem.