Multiple bugs in timer conflict resolution

[prl]

• When you navigate up and down, the BLUE button labels aren't updated to reflect the changes in the respective timer entry. This is trivial to fix.
• I don't think it's possible to get into a state where the BLUE button hint text is Enable, but perhaps it's a bit belt-and-braces.
• LEFT and RIGHT jump to the bottom and top respectively of the list with the "Conflicting timer" text entries, but they don't move the highlight in the list of the actual conflicting timers. Think that the parent Screen class is moving the top list, but the method needs to be overridden in TimerSanityConflict class to move both lists.
• The Disable text is shown in the BLUE button hint when the timer with focus is not running (which is correct) but also when the timer is a running repeat timer, but not when it's a running "once" timer.
• When BLUE Disable is pressed on a running repeat timer, it enters the method that changes the enable/disable state of the timer, but the code only sets the timer to disabled if it's not running.
• If the code is changed to allow a running timer to be disabled, its recording is stopped and the conflict is resolved.

I think that the code should be changed so that running timers can be stopped in order to resolve a conflict, because the only alternative is to always reject the creation of the new timer, and the BLUE button should show "Disable" for timers that aren't running and perhaps something like "Stop & Disable" for running timers. The internal Enable state for the BLUE button should possibly remain, even though I can't think of an execution path that would have it in that state.

I have a fix implementing those suggested changes ready to submit to the repository.

Reproduction steps

Create a timer conflict where at least one of the timers set up before the conflicting timer is a running "once" timer, one is a running repeat timer and one is a non-running timer..

The text on the BLUE button does not change.

To reproduce the other bugs requires fixing that first bug in order to see them.

[prl]

The issue was updated with the following change(s):

• This issue's reproduction steps has been changed

[Peter Urbanec]

The issue was updated with the following change(s):

• The status has been updated, from New to Testing.

[prl]

The issue was updated with the following change(s):

• The status has been updated, from Testing to Closed.
• This issue has been closed
• This issue's progression has been updated to 100 percent completed.
• The resolution has been updated, from Not determined to Fixed.