Map product for Imap-Lo

[vineetbansal]

Closes #3349

The Imap-Lo L2 maps now no longer derive from the l1c psets (the Lo team and Nathan are fully aware of this and have endorsed this path forward), but from l1b products like histrates, goodtimes, and bgrates.

The approach in lo_l2 now is a direct counterpart of the offline processing that the team has been doing, and has been approved by the team as being broadly correct. A more systematic validation will come soon when this code is available upstream and everyone can access/generate these products. Hopefully these tweaks will be minor.

Since the original lo_l2 code was written a while ago and never exercised or validated, I found little need to keep it in here - I can always go back to the old code and re-introduce parts of it (sputter correction, bootstrap correction etc). as I incorporate those corrections incrementally. For now, perhaps this PR is best reviewed as a new implementation instead of an incremental update (i.e. looking at the whole file instead of a diff against the old one). I think seen in this light, the whole approach this code is taking is quite straightforward.

Unlike the previous attempt, I'm now using compute_pointing_directions from the library as well as RectangularSkyMap. Any remaining code redundancies you see are a result of my own ignorance of what else is out there in imap_processing, rather than an attempt to rush things!

[jtniehof]

The plan is still to create the l1c, correct? Just not needed for the map production?

[tmplummer]

This looks fine to me. Sad to see so much code that Greg and I wrote to Nathan's algorithm document get thrown out, but that isn't your fault.

[vineetbansal]

@jtniehof - l1c psets are currently being created by the pipeline, with no plans to remove them. It's just that they accumulate counts from l1b direct events, and all of Nathan's work is based on histogram data instead, so they are unused.

Since I'm creating an in-memory LoSpinAnglePointingSet in here anyway (to take advantage of a lot of the mapping code already written), a future PR might/(should?) fix the creation of psets to accumulate histogram counts and pass it in as a dependency directly, which will get rid of some of the redundancy here.

[vineetbansal]

thanks for the review @tmplummer - I think that a lot of your original code that was removed in this PR will come back soon (even as soon as later today), as I go through it more and understand it better - its just that it would have interfered with this first PR.