analyze-bright-ptsrc: next steps

[mhasself]

PR #574 has dealt with most of #479. Here are some requests (residual and emergent), prioritized:

1. Make not crash on site environment. The current script likely doesn't work on data at site, if for no other reason than that the sso_name is taken from an obsdb column that does not exist at site. A solution more compatible with SO obsdb would be to try to find a planet name in the obsdb "tags"; but is must always be possible to override from cmdline / config file.
2. Revise the output file format. Is time constant not in there? xi0 and eta0 should be called xi and eta. Do an iteration with consumers on what makes most sense here.
3. Document. it is especially important to capture what the config file should look like! This is hard to put together, just scanning the code. Documenting the output file is pretty important too -- these fit results are important intermediate data products that will get used a lot.
4. Some way to get priors in; especially priors on position. A common use case will be: we know where the detectors are, but we want to run time-domain fitting to refine the time constants.
5. Account for boresight/corotator value. This will require some thought; but we'd be wise to at least record in the output data (a) what the boresight value for the observation was and (b) whether that was included in the model during fitting or not.
6. Transfer supporting functions to library level. I have heard that much time domain fitting is being done in Jupyter notebooks, presumably using functions extracted and evolved, from this script. Let's start making some of those things available at library level.

[mhasself]

From the comments in #516, we have learned of the config file example here.

[mhasself]

For "quick position fit" additions in #750:

• In quick fit code, un-hardcode "moon". For LAT you'll be able to do this with other sources.
• If not fixed on merge, state units in function + dataclass docstrings.