New Greedy Algorithm for Scheduler

This MR now adds an alternative scheduling algorithm, called the Greedy Algorithm, or Greedy Scheduler. It will attempt to fill the time so the telescope is busy all night, if the user provides enough scheduler jobs. Like the classic scheduler, it tries to maintain a priority list, preferring jobs earlier in the list. However, if it can fit in some time before a preferred job can start, it runs the highest priority runnable job until that preferred job can start. This works well for multi-day scheduling, or single-day scheduling.

This does not affect the classic algorithm, if the user chooses that, then jobs will be scheduled as they have in the past. (See disclaimer at the bottom re rememberJobProgress).

There is a UI choice for algorithms on the scheduler tab, defaulting to 'classic', and the users choice is stored in the .esl file that's saved, and restored for that loaded schedule.

I have added significant testing for this (see test_ekos_scheduler_ops.cpp). I have run on my telescope several nights and things have run well.

I am excited about this, I think it can add a new way for folks to use Ekos. The bottom line is that this can increase the usage of your imaging system. I'd recommend for users to add, in addition to some primary targets, some background targets that could be run when the primary targets can't image. Ideally Ekos would images all night, capturing as many images of the main targets as possible, and also filling in background targets when it can.

Job priority is simply the order of the jobs (with an exception for StartAt which I've tried to give highest priority to).

Screenshot: https://drive.google.com/file/d/1WjQ0g3ZFDNWEisRtS50nHqz255Lfmy87/view?usp=sharing You can see I have enough jobs to keep it busy all night. My real target is Sombrero (M104) but that's only visible to me for 3.5 hours. 

Status: I am now feature complete for Greedy Scheduler version 1.0. I have been testing every night, but the weather is now bad for several days. I have refactored/commented code and removed Draft. I will follow-up with a separate MR to introduce a scheduler algorithm interface class.

Disclaimer: There is one change that does affect the way the classic scheduler would work. I could make this an option or tie it to the Greedy Scheduler, but I believe both schemes benefit from this change. The change relates to the way "Options::rememberJobProgress()" works. Previously that did not apply to LOOP or STOP_AT jobs. Now it applies to all stopping conditions. Previously it made no attempt to balance the various subjobs (i.e. filter captures). It will now look at the progress in the different filters/keys and attempt to equalize what's been done. That is, if one filter has gone through 10 repeats (e.g. because it's first and the job was consistently pre-empted after that filter) and another filter has only gone through 1 repeat (because of those same preemptions), the scheme will focus the captures on the more needy filter until things are balanced. I believe that's more in the spirit of "rememberJobProgress".