Refactor convolve scanner factory functions

[dylanhmorris]

Ready for review.

This PR:

• Renames new_double_scanner to new_double_convolve_scanner for consistency.
• Closes Add transforms to new_convolve_scanner, make identity transforms default for new_double_scanner #147 by adding transform functionality to new_convolve_scanner
• Improves documentation for both scanner factories.
• Adds a unit test for the convolve scanner functions (which previously did not have one)
• This does not have default transforms as on reflection factories this low-level probably should not have defaults at all.

Out of scope

• More tests needed but I think that is a separate issue/PR.
• Also separate: a factory for convolve scanners that carry along either the full history (more general / less efficient) or cumulative incidence (less general / more efficient). That is needed to implement susceptibility adjustments that depend on keeping track of cumulative incidence (e.g. the logistic_susceptibility_adjustment)
• Replace new_convolve_scanner and new_double_scanner function factories with ConvolveScanner classes? #177

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.78%. Comparing base (48b7471) to head (b5178a6).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #161   +/-   ##
=======================================
  Coverage   94.77%   94.78%           
=======================================
  Files          39       39           
  Lines         842      843    +1     
=======================================
+ Hits          798      799    +1     
  Misses         44       44           

Flag	Coverage Δ
unittests	94.78% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[gvegayon]

Looks good! Just a couple of comments.

[damonbayer]

Should we check the size/shape/type of inputs?

[dylanhmorris]

Should we check the size/shape/type of inputs?

@damonbayer are you talking about checking the inputs to the factories or about having the functions they produce/return perform input checks?

[damonbayer]

@damonbayer are you talking about checking the inputs to the factories or about having the functions they produce/return perform input checks?

Checking inputs to factories so we can provide useful errors.

[dylanhmorris]

Things that occur to me:

1. Check that the double scanner tuples are of exactly length two. As written, it will error if they are less.
2. Check that the dists are ArrayLike and the transforms are callable.
3. Check that the pair of dists are of the same length (in the future, we might want to have the double scanner just use history subsets of the length of the longer array, and automagically sub-subset when taking the dot product with the shorter array, but that feels a bit implicit.

Stricter stuff that I'm more reluctant to implement:

1. Could try to check that the transforms are shape-preserving for jax arrays, but that's a bit tricky.
2. Could force the arrays that go into the dot products to be flat.

Anything else you had in mind @damonbayer?

[damonbayer]

@dylanhmorris Sounds good to me.

[gvegayon]

All looks good. Test pass and the website is rendered correctly.