When no valid grouping could be made, an empty header would be printed
(0 length group label, zero = characters below).

The empty tuple represents the initial grouping.

Fixes #153

This reverts the first attempt (commit
8310b029), because relative dates in terms of
hours were printed.

This attempt passes the now object that we just created to humanize(), so that
will be used as a offset. If we don't supply that object, arrow will create a
different datetime object representing 'now', which might be slightly off
w.r.t. the now object we created.  Therefore the floating point arithmetic done
within the arrow library might not produce the desired results (delta / 86400).

By passing the offset ourselves I was able to produce reliable
results.

With the previous method of using arrow, the same date object would
result in different humanized dates. Apparently using now() and then
replacing the date components triggers some inaccuracy.

Simplify the call to arrow by passing it the datetime object directly.

It will simply gather all todo items in all groups and pass them to
print_list

When grouping by project, todo items without a project wouldn't be
listed (same for contexts).

Moreover, sort the projects such that the items without project are
shown at the bottom of the list.

Also, the label of a field is passed in the output of the group()
method.

When grouping takes place, don't sort the full list of todo items first
and then group. Because the todos in the group won't necessarily match
the given sort expression, for those items which match multiple groups.

These are the steps instead:

1. Get all todo items
2. Filter them
3. Pre-order them according to the group expression
4. Split in groups using groupby()
5. Then sort the individual groups according to the sort expression

Otherwise it's hard to test the output when the order differs on every
execution.

For example, when grouping by project, a todo item in two groups will be
added to each applicable project.