Split pfsConfig into pre- and post- mapping files.

The current pfsConfig mechanism covers two different concepts: the design of a targeted field, which is the input to the FPS cobra motion process, and the instantiation of that field where both the measured cobra positions and the starting visit number are known.

Discussions have led to the suggestion that we should split pfsConfig into:

• pfsFieldDesign, specifically pfsFieldDesign-$configId.fits
• pfsConfig, specifically pfsConfig-$configId-$visit0.fits

The only significant internal difference would be the MCS positions and the PFS visit from which the field is valid. Given that, the final pfsConfig could either refer to the pfsFieldDesign, or include it. I think we should denormalize and include it: that single $pfsConfig-$configId-$visit0 would then neatly contain all that we need to know about field.

A couple of notes: the $configId is not strictly necessary in the pfsConfig file name, since only one configuration can be active at any given time (visit+}. But binding the two seems informative.