Rename trace file extensions to match grating efficiency filenames

[Isa29bella]

This used to be identical in the previously default *_sci.fits trace files, and causes a silent error when attemting to include the trace efficiencies.

Created in cooperation with @teutoburg

[hugobuddel]

For the curious reader (that is, me), this is what changed (and similar for the other bands):

fitsdiff  TRACE_LSS_L.old.fits TRACE_LSS_L.new.fits

 fitsdiff: 5.3.4
 a: TRACE_LSS_L.old.fits
 b: TRACE_LSS_L.new.fits
 Maximum number of different data values to be reported: 10
 Relative tolerance: 0.0, Absolute tolerance: 0.0

Extension HDU 1 (TOC, 1):

   Data contains differences:
     Column description data differs in row 0:
        a> 2023-06-20-spectra_Grism-L_band
        b> METIS LSS L
     1 different table data element(s) found (25.00% different).

Extension HDU 2:
   Extension names differ:
    a: 2023-06-20-spectra_Grism-L_band
    b: METIS LSS L

   Headers contain differences:
     Keyword EXTNAME  has different values:
        a> 2023-06-20-spectra_Grism-L_band
        b> METIS LSS L

@teutoburg should we add a test to prevent such problems in the future when we get new traces?

@astronomyk should we add this fix to whatever conversion script you used to convert the new traces?

[hugobuddel]

And thanks @Isa29bella ! Such a PR is much appreciated

[teutoburg]

@teutoburg should we add a test to prevent such problems in the future when we get new traces?

Absolutely. The issue here (or not really an issue but just something to be aware of) is that the SpectralTraceList assumes that the names of the efficiency extensions are identical to those of the trace definitions. See also the docstring of SpectralEfficiency.

So actually, all IRDB packages that use traces and efficiencies should have a standardized test that simply checks if those match.