Colour baseline bars by duration, and draw one when only the duration changed

[Natalie-the-technician]

Symptom

Two things go wrong when a task is compared with its baseline.

1. A task whose end date did not move gets no baseline bar at all, even when
   its duration changed. A task which used to take 3 days and now takes 5 while
   still finishing on the same day shows nothing.
2. The "earlier" and "later" colours are chosen by end date, so a task which
   was only moved — same duration, later finish — is painted in the "task
   completes later than before" colour, as if it had grown.

Cause

GanttChartSceneBuilder.renderBaseline compares end dates only:

if (endDate.equals(t.getEnd().getTime())) {
  return;
}
...
if (endDate.compareTo(t.getEnd().getTime()) < 0) {
  styles.add("later");
} else {
  styles.add("earlier");
}

The early return is the first symptom. The if/else is the second: every
deviating task gets one of the two colours, and which one depends on the end
date alone.

There is a third consequence which is easy to miss. StyledPainterImpl knows
three colours for a baseline bar — earlier, later, and a neutral one:

if (next.hasStyle("earlier")) {
  c = myConfig.getEarlierPreviousTaskColor();
} else if (next.hasStyle("later")) {
  c = myConfig.getLaterPreviousTaskColor();
} else {
  c = myConfig.getPreviousTaskColor();
}

The neutral colour is a configurable option, labelled Task remains on schedule. Because the code above always adds one of the two styles, that
branch is unreachable today: the option can be set but never shows up on a
baseline bar.

Fix

The decision is moved into a static method which takes the two durations and
the two end dates, so it can be tested without a chart:

• unchanged means same end date and same duration; only then is no bar drawn;
• later means the task now takes longer than in the baseline, earlier
  means shorter;
• a task which only moved gets neither style and is drawn in the neutral
  colour — which makes that existing option reachable.

renderBaseline keeps its structure; only the block above is replaced by a call.

Testing

New BaselineStylesTest: 9 tests, covering an unchanged task, a moved task, a
longer task with an unchanged end date, a shorter task ending on the same day,
and a milestone.

Verified the other way round as well: with the old logic put back into the new
method, 5 of the 9 fail, among them
expected: <[later]> but was: <null> (the missing bar) and
expected: <[]> but was: <[earlier]> (the wrongly coloured moved task).

A question about the labels

If the colours mean duration rather than end date, two existing option labels
no longer say the right thing:

option.ganttChartStateDiffColors.taskAheadOfScheduleColor.label=Task completes earlier than before
option.ganttChartStateDiffColors.taskBehindScheduleColor.label=Task completes later than before

Both talk about completing, which is end-date language. Something like "Task
takes less time than before" / "Task takes more time than before" would match
the new behaviour, and the third label, Task remains on schedule, would then
apply to a task which was only moved.

I have deliberately not touched the translations: the wording is yours to
choose, and changing the English string alone would leave every other language
saying the old thing. Happy to add whatever wording you prefer, or to leave it
to you entirely.

[dbarashev]

The "earlier" and "later" colours are chosen by end date, so a task which
was only moved — same duration, later finish — is painted in the "task
completes later than before" colour, as if it had grown.

But isn't it the point of project scheduling -- to be alarmed when your project is going to be delayed? I wouldn't care too much if my task becomes longer of shorter, provided that it meets the end date deadline.

[Natalie-the-technician]

This is Taken over bei #2849