Save 600+ bytes RAM (step 6 of 9) - De-duplicate schedule structs

[adbancroft]

This is the 6th PR in a series of scheduler focused PRs that end up saving >600 bytes RAM (compared to master as of 2023-06-11)

This PR:

1. Removes duplication from the IgnitionSchedule and FuelSchedule structs by deriving them from a common base struct, Schedule.
2. Optimizes the memory footprint of Schedule.

See #1111 for more the context on this PR.

[adbancroft]

A couple of changes worth close scrutiny:

1. Removal of timer start/stop function pointers from Schedule. Shouldn't do any harm, as the scheduler state will be OFF & the ISR will do nothing. Plus I think the timers are very likely running the whole time anyway - loop() set's them on every cycle. See https://github.com/noisymime/speeduino/pull/1140/commits/a7f1312dfc461346bf23fcf63532683c69a80509
2. Removal of endCompare from Schedule. See https://github.com/noisymime/speeduino/pull/1140/commits/721b8d4692f626b34f0d3817ae44c6c84c9fbe05

[TBAMax]

At first glimpse of look seems like the setFuelschedule() needs to be wrapped inside the nointerrupts(); interrupts(); Because the interrupt can occur between checking the schedule state and actually taking action(). This means the possibility of re setting the already RUNNING schedule and thus whole cycle wide injection pulse. Do check with the scope, set to trigger at wider than normal injection pulse, and see if there are some abnormally wide pulses randomly over some period of time! First impression, I might be mistaking, but I think worth to having second look with this in mind.

[adbancroft]

At first glimpse of look seems like the setFuelschedule() needs to be wrapped inside the nointerrupts(); interrupts(); Because the interrupt can occur between checking the schedule state and actually taking action(). This means the possibility of re setting the already RUNNING schedule and thus whole cycle wide injection pulse. Do check with the scope, set to trigger at wider than normal injection pulse, and see if there are some abnormally wide pulses randomly over some period of time! First impression, I might be mistaking, but I think worth to having second look with this in mind.

You are correct - I left it out since the original code base didn't protect against race conditions. I've fixed this for the setSchedule functions in this PR.