Enabling MIRI Photometry

[taylorbell57]

This PR enables the use of Eureka! for MIRI photometry.

In particular, this PR:

• Edits miri.py's read function to permit photometry files
• Adds the required flag_bg_phot function to miri.py (just calls NIRCam's function)
• Edits miri.py's read function to better handle simulated data without INTSTART and INTEND header values in the FITS files
• Fixes some minor bugs with plots 3503 (not writing over previous plot and consuming excessive RAM; also wasn't being limited by meta.nplots), 3306 & 3504 (hardcoded vmin and vmax weren't good for all datasets), 3505 (run for all integrations and not limited by meta.nplots)
• Changes the behaviour of meta.skyin and meta.skyout if they are lists. Previously, there were no protections against skyin being larger than skyout, so the new method assumes that there is one skyin value for each skyout value. In otherwords, if skyin=[10,11] and skyout=[15,16], previously the code would've tried 10-15, 10-16, 11-15, and 11-16 annuli while now it will just do 10-15 and 10-16. That's important in the case of skyin=[10,15,20], skyout=[15,20,25], where the old algorithm could do some pretty dangerous things.
• Makes running the b2f.convert_to_e function optional (but run by default if the new meta.convert_to_e parameter is missing). This is important to calculate flux-calibrated stellar photometry.
• Allows a manual first-guess of the centroid position rather than the currently implemented full-frame centroid fit. For the NIRCam photometry, the full-frame fit isn't too far off since the PSF is huge and the star is bright, but for MIRI the star is very small and not much brighter than the background (in some filters at least) and there's also significant non-uniformities in the huge full-frame images which make the full-frame centroiding even worse. Users can now pass in meta.ctr_guess with the manually generated x,y guess for the centroid (using the pixel indices before xwindow and ywindow are applied).
• Adds a new ECF template for MIRI photometry
• Documents all added/changed ECF parameters

This PR also:

• Resolves #490 (Using skyin and skywidth is probably the safer choice though, and if you agree I can switch to the approach I suggested in that issue)
• Resolves #313 (Extends photometry support to MIRI, the second and only other JWST instrument that allows photometry to my knowledge)

I think @sebastian-zieba also had a MIRI photometry branch under development. Depending on how close that is to being ready for a PR, we can either:

1. Merge this PR first and then merge in Sebastian's code when it's ready
2. Merge Sebastian's PR into this branch and then merge this branch into main

[codecov-commenter]

Codecov Report

Merging #504 (e4e57d3) into main (c38bb2c) will decrease coverage by 0.04%. The diff coverage is 43.20%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main     #504      +/-   ##
==========================================
- Coverage   59.63%   59.60%   -0.04%     
==========================================
  Files          87       87              
  Lines       10079    10124      +45     
==========================================
+ Hits         6011     6034      +23     
- Misses       4068     4090      +22     

Impacted Files	Coverage Δ
src/eureka/S3_data_reduction/nircam.py	72.39% <ø> (ø)
src/eureka/S3_data_reduction/miri.py	53.14% <32.72%> (-12.90%)	:arrow_down:
src/eureka/S3_data_reduction/plots_s3.py	75.00% <58.33%> (+0.19%)	:arrow_up:
src/eureka/S3_data_reduction/s3_reduce.py	90.03% <66.66%> (-1.27%)	:arrow_down:
src/eureka/lib/centerdriver.py	92.30% <100.00%> (ø)
src/eureka/lib/util.py	79.08% <100.00%> (ø)
src/eureka/lib/utc_tt.py	88.52% <0.00%> (+19.67%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[taylorbell57]

Alight, I think I've addressed all your comments (aside from the edits that need to wait for #502 to be merged).

I do, however, want your opinion on whether I should continue using skyin and skyout as is currently done or instead use skyin and skywidth to make it impossible to have skyout < skyin and to make it a bit easier to loop over different aperture options (using an n*m grid of skyin and skywidth values instead of having to specify one skyout for each skyin)