FHD-style beam decomposition

[bhazelton]

Description

Add support for two new types of beams which are the two parts that FHD decomposes Jones matrices (E-field beams) into.
While these are needed by FHD, I suspect they might be more broadly useful to other simulators as well. I currently need them for pyFHD and it really makes the most sense to implement them on UVBeam because the decomposition needs to be done before interpolation.

The two new types of beams are:

• The response of each feed to unpolarized emission. This is a complex quantity with Naxes_vec=1 (because this is the response to unpolarized emission) and a feed axis of length Nfeeds. The complex phase is related to time delays which can vary across the sky but are shared between the two incident polarizations. This is currently called "feed_iresponse" but I'm very open to other names.
• The part that remains after dividing the Jones matrix by the above quantity for each feed and incident polarization direction. This represents how much each feed responds to each incident polarization direction. This is similar to a rotation matrix in that it effectively projects from the incident polarization vector directions to the directions of the feeds (the magnitude of the response is removed), but is not unitary because the projection of the feeds are not orthogonal in all directions on the sky. This is a complex quantity with the same shape as the efield beam (Jones matrix). This is currently called "feed_projection" but I'm very open to other names.

This PR adds support for these two new kinds of beams to UVBeam, AnalyticBeam and BeamInterface objects.

To Do:

• decide on good names for these beam types!
• update the tutorial (not sure how much to do here)
• update the changelog

Note:
This PR is branched off of #1639, so it includes those updates and that PR should be merged first.

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation change (documentation changes only)
• Version change
• Build or continuous integration change
• Other

Checklist:

• I have read the contribution guide.
• My code follows the code style of this project.

New feature checklist:

• I have added or updated the docstrings associated with my feature using the numpy docstring format.
• I have updated the tutorial to highlight my new feature (if appropriate).
• I have added/updated tests to cover my new feature.
• I have updated the CHANGELOG.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.92%. Comparing base (2ca5e6f) to head (d608b33).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1641      +/-   ##
==========================================
- Coverage   99.93%   99.92%   -0.01%     
==========================================
  Files          67       67              
  Lines       22682    22815     +133     
==========================================
+ Hits        22668    22799     +131     
- Misses         14       16       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[steven-murray]

missing "to"

[steven-murray]

Suggested change

	The feed I response is the the complex response of each instrumental
	The feed I response is the complex response of each instrumental

[steven-murray]

Suggested change

	feed to unpolarized emission (so it only has an feed index, no vector
	feed to unpolarized emission (so it only has a feed index, no vector

[steven-murray]

Can we get a mathematical definition, or link to a definition, here? "Related to time delays" is a little hard to understand :-D

[steven-murray]

@bhazelton can I perhaps suggest per_feed_unpolarized_response instead of feed_iresponse? It's more of a mouthful, but more descriptive. I dunno what to call the other.... feed_projection is maybe OK. Projection is not very descriptive, but I honestly don't understand the formulation here well enough to suggest otherwise.