Implement differentiable satellite quenching

[aphearin]

This PR brings in a dev version of phot_kernels._mc_phot_kern. The implementation is in a new module, gd_phot_kernels.py. There is a unit test that ensures that gd_phot_kernels._mc_phot_kern and phot_kernels._mc_phot_kern return identical results for the stochastic obs_mags quantity. The gd_phot_kernels._mc_phot_kernfunction returns a bunch of additional quantities, includingobs_mags_weighted. The figure below shows that histograms of obs_magsandobs_mags_weighted` are very similar.

[aphearin]

I have not made any attempt to optimize the new implementation, and so it is much slower and more memory intensive than the original module, because many redundant calculations are being done. I wanted to start with code-correctness before proceeding to optimization.

[aphearin]

A couple of scattered notes for future work on this PR:

First, a list of functions we should consider replacing:

• ssp_weight_kernels.get_dust_randoms it would be more logical for this to instead be implemented in mc_randoms
• sspwk.compute_burstiness is now obsolete and the bug-fixed code now calls sspwk.get_burstiness, so we should probably outright delete sspwk.compute_burstiness. However, there is still some considerable refactoring that will need to be done to improve efficiency of these implementations, so this can wait for now.
• Same goes for sspwk.compute_diffstar_info- the corrected code is now based on sspwk.get_diffstar_info.

Separately, diffmerge is based on t_infall, whereas diffstarpop is based on gyr_since_infall = t_obs-t_infall This is a likely source of future confusion/bugs. Fortunately, these variable names are very clear to interpret, and I think I have consistently used them throughout the code. But this should be double-checked before we merge this eventual PR into main. And we should at least consider re-implementing these models so that the user-facing functions in each model accept the same convention.

[aphearin]

The code in this PR has been used by both @zaidikumail and @MitraKaustav in gradient descents, and the rapid quenching implementation has been stress-tested by @zaidikumail, so I'll proceed to merge this into main, and cut a new minor release so that we have a tagged version of the code with science validation tests.

[aphearin]

Note that #424 was a closely related investigation to this PR, I think maybe we should close #424 now that we found a better solution to the blue merging problem, but @zaidikumail should confirm before we do that.

[zaidikumail]

Note that #424 was a closely related investigation to this PR, I think maybe we should close #424 now that we found a better solution to the blue merging problem, but @zaidikumail should confirm before we do that.

Yes, we can close #424