Backport #212 improve report generation to 4.3.x

[taldcroft]

This could be slightly controversial, but I was thinking about options for aca_preview to generate report pages for obsids that have warnings above a specified level (e.g. everything with warning or critical messages). This would presumably speed up diagnosis.

So I had the idea to just "quickly" backport #212 since the footprint of that PR is outside of the core code apart from adding make_report methods. Unfortunately the merge had conflicts, and even after that there were a few post-cherry-pick issues that needed hand-fixing, so the "quickly" was optimistic. But it does seem to be working now and passing all tests.

Until just now I didn't actually appreciate that 4.3.2 does not have any guide reporting. So this PR is basically necessary if we want to have 4.3.x in ska3-flight and use it for production ACA review (starcheck) as well. Somehow maintaining this concordance seems like the right thing.

[jeanconn]

I thought the bonus of making aca_preview compatible with 4.4 or 4.3.x was that we could promote 4.4 on ska3/flight and not really need to do this backporting. We wouldn't have the best native reporting in the ska3/matlab version but as soon as ACA insight became required we'd have no problem running the tools for more reporting.

[jeanconn]

Given the scope of the changes in acq.py, guide.py, and catalog.py, this seems perfectly safe for 4.3.3, I just don't really see the point in putting more stuff in the 4.3.x branch.

[taldcroft]

The point is that the FOT are going to be running 4.3.x, and while we have the chance (last opportunity in 5 months), I want to push any easy-ish changes to proseco and aca_preview.

The workflow I am imagining is FOT MP running aca_preview, seeing critical errors, and having them send us a link sufficient for all of the ACA reviewers to provide quick feedback in most cases. The bar is fairly low for critical errors so I expect to see them for many (most?) loads.

[jeanconn]

OK. That's fine. I had just envisioned our reporting to explicitly not be frozen for 5 months so I figured we'd be running a reporting process as needed. But as I said, given the scope of changes in acq, guide, catalog, this seems safe, so if you want to go with it that's fine. I'm not sure what scope testing makes sense.

[jeanconn]

I'm assuming that the only issue if there is a bug in here would be that a user would need to run aca_preview --report-level none if there were an unhandled exception in the report gen code called from a the aca_preview environment.