Correctly account for grism time series intermediate apertures

[bhilbert4]

First reported by @eas342.

Grism time series observations have the trace of the source in the wrong location. The trace is showing up in row 57, rather than the expected row 34.

This is due to an oversight in the way Mirage deals with the intermediate apertures used by APT in grism time series observations.

Operational summary:
Once the source is located in the preceding TA image, the telescope will shift to place the source at the reference location of an intermediate aperture, rather than the final grism time series aperture. This intermediate aperture has a reference location that is offset from the reference location of the requested aperture. The offset is defined so that the undispersed source will land on the detector in the appropriate location such that, once the grism is placed in the beam, the trace of the dispersed source will land at the reference location of the requested aperture.

So, a requested aperture of NRCA5_GRISM[256,128,64]_F444W will use the intermediate aperture: NRCA5_TAGRISMTS_SCI_F444W
Requested apertures of NRCA5_GRISM[256,128,64]_[F277W,F356W,F322W2] will use the intermediate aperture NRCA5_TAGRISMTS_SCI_F322W2

Note that the shortwave observations that accompany the grism data will also be affected. The location of the source in the SW observations will depend on which intermediate aperture is used, which in turn depends on the filter used in the LW channel.

Currently, Mirage takes all of this into account when creating the yaml files from the APT files. The RA, Dec of the pointing within each yaml file is correct. However, when catalog_seed_image.py is called, it creates the local roll angle and attitude matrix using the requested aperture rather than the intermediate aperture. Source positions on the detector are calculated using these values, which is causing them to be incorrect.

Possible Fix:
We need to define an attitude_matrix and local roll angle for the intermediate aperture (while keeping all other SIAF-related info for the requested aperture). This should then allow for the correct x,y positions for sources to be determined. The complication comes in when trying to simulated the accompanying SW data. In this case, we don't know which intermediate aperture to use. The only solution I can think of for this would be to add a new entry to the yaml file that specifies the intermediate aperture name. If we were only simulating LW data, then an easy-if-hacky solution would be to simply decrease the pixel y values of all sources by ~24 rows. But we can't do this in the SW because the two intermediate aperture options have different locations along the x axis and we have no way of knowing which to use.

[bhilbert4]

I have a branch that I think corrects this problem. In testing it, I found what may be a second problem. The location of the source is lower (i.e. a lower y pixel value) in the undispersed image compared to the location of the trace. That's the opposite of what I would expect given the reference locations of the intermediate aperture vs the grism tso aperture. Looking at the V2, V3 reference location of these apertures, the intermediate aperture is higher up the y-axis than the grism TSO aperture. So I think that the disperser may have a sign error, where it is calculating the trace location by adding the offset between the apertures to the undispersed source location, when if fact it should be subtracting the offset. @NorPirzkal is looking into this possibility.