select calib dark with most cameras; fixes 20231028 for Jura

[sbailey]

This PR fixes #2247 where the pipeline was generating a ccdcalib job for camword a01456789 but later needing CTE corrections for z3 not included in that camword.

The underlying reason was that the job camword is tied to the selected dark, and select_calibrations_to_proc was picking the first calib dark instead of the one with the most available cameras.

With this PR, desi_proc_night -n 20231028 --dry-run-level 1 now selects a different dark and generates a ccdcalib job for all cameras.

20231028 is the only night in Jura that I'm aware of that is impacted by this issue, though it is possible that other nights would pick a different dark with this branch.

Additional notes:

• I pulled the dark selection out into a function select_calib_dark(etable). Upstream from that function the etable had already been filtered to 300 second darks. In general, I think we'd prefer a longer dark with more cameras over a 300 sec dark with fewer cameras, but I'm unaware of a night where that distinction matters so I didn't change that here. In the future select_valid_calib_exposures could be more permissive about what dark exposure times are allowable, and this new function select_calib_dark could include EXPTIME in its ranking consideration.
• tying the ccdcalib camword to the dark camword is in principle more restrictive than it has to be, but I'm also unaware of a case where the best dark has fewer cameras than the set of zeros, so that distinction also may not matter (for now at least).

[sbailey]

Good idea. I updated select_calib_darks to return a Table instead of an index. Currently this is a Table of length 1, but in general in the future it could be a longer table to I made the function name plural and return a Table not a single Row object. This also simplifies its use with vstack with the other calib tables.

[sbailey]

Design note: as originally implemented, select_calib_darks would raise a ValueError if no good darks were found. That breaks the updated test_missing_cals test when merged into main, so I updated this to return a length-0 table instead. Yay for unit tests; the updated test in PR #2254 just prevented us from accidentally re-breaking that code with this PR.