Update spherex_qr -> spherex_qr2

[troyraen]

Closes IRSA-7323
Closes IRSA-7363

Do not merge until SPHEREx QR2 has been released and is available in SIA.

SPHEREx QR2 is scheduled to be released on October 1416, available in SIA a day or two later. This PR updates notebooks to use it. I think that only the collections names will need to be updated but we'll need to test this once QR2 is available in SIA on irsatest, likely on October 13.

[bsipocz]

The text is likely needs to be updated, too.

[troyraen]

I added a couple of simplifications and fixes for minor things in the SPHEREx notebooks. The only build-docs error right now is an IndexError in spherex_intro.md due to this PR which is expected until QR2 is available in SIA. ETA is end of this week or early next. After that happens, need to test this against ops before merging.

[troyraen]

All three SPHEREx notebooks run successfully on Fornax. However, spherex_cutouts.md is failing the circleci build with the following error. I am investigating.

⛔️ tutorials/spherex/spherex_cutouts.md An exception occurred during code execution, halting further execution:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[9], line 3
      1 primary_hdu = fits.PrimaryHDU()
      2 hdulist_list = [primary_hdu, table_hdu]
----> 3 hdulist_list.extend(hdu for fits_hdulist in results_table_parallel["hdus"] for hdu in fits_hdulist)
      4 combined_hdulist = fits.HDUList(hdulist_list)

Cell In[9], line 3, in <genexpr>(.0)
      1 primary_hdu = fits.PrimaryHDU()
      2 hdulist_list = [primary_hdu, table_hdu]
----> 3 hdulist_list.extend(hdu for fits_hdulist in results_table_parallel["hdus"] for hdu in fits_hdulist)
      4 combined_hdulist = fits.HDUList(hdulist_list)

TypeError: 'NoneType' object is not iterable

[troyraen]

CircleCI failure was transitory. Not sure what happened but all looks good now. This is ready to go.

[bsipocz]

Should be ready to go.

The traceback sometimes is incorrect as the error/unexpected behaviour occurs a few lines above, I suspect a non-tracebacking query was the culprit for that sporadic failure you saw.