Remove the implicit interpretation of due date through get_due_date: 


With this patch, GTG uses the actual value of the task object's due date 
when accessing it through get_due_date.

It seems to me that it's saner than the current mechanism that relies
on an on-the-fly interpretation when accessing the due date. Indeed, 
this can hide mismatches between the stored value and the returned due
date.

Typical example: a parent task with due date A and a child task 
with no due date: the child has no due date set, but get_due_date 
will return 'A'.

Now, you get what you really have stored, but therefore it's up to the
code to make sure you store a correct value!

Therefore, from now on all code dealing with tasks due dates and
tasks relations MUST be written so that the due dates are always set
correctly (=they respect the date constraints). This is actually not
a big deal since most of this is actually cared for by set_due_date().

set_due_date() has thus been slightly modified (pursuing previous 
work by Nimit Shah), so that when you set/update the due date, all 
related tasks dates are modified to respect the constraints.

However, D&D'ing tasks can still create situations where a parent task due 
date and its child due date are not compatible. This cannot be fixed 
now since D&D is done in liblarch and there are no hooks available
from the GTG code to handle tasks updates when reparenting them...

This patch also means that from now on, undefined due date are presented 
explicitely in the list as not being set, even when constrained by a
parent. Therefore, it's up to the user to explicitely define it if needed
(which she/he can do by directly setting the due date of the task, or by
setting the due date of the parent). It's possibly more work for her/him,
but at least the outcome is clear and therefore predictable/usable: explicit
is always better than implicit.

Note: some code from the task editor that checks if the start and due
date are compatible has been removed, since it's done in set_due_date
now.