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

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

This is applicable for prompt mode and column mode. Changes are
immediately read whenever todo.txt is changed.

Current issues:

* Writes caused by the current topydo instance also trigger the file
  update: needless overhead.
* Column mode: items are not immediately redrawn on update

This mostly addresses issue #142.

On Travis CI, the pypy3 tests may fail due to concurrency issues,
probably because of the usage of (shared) temporary files.

So, limit the number of processes used by green to 1 when pypy3 is used.

This implies that failures for pypy3 are no longer allowed.

Too many (random) failures.

Support user-specified column-layout file

User can now use '-l' option with an argument *after* 'columns' command
and topydo will try to load column layout from that location. If it
won't find specified file it will use standard column-layout file
locations as a fallback.

Example of use:
Will work: `topydo columns -l ~/fooBar_columns`
Won't work: `topydo -l ~/fooBar_columns columns`

Implements #147

That way the filetype detection of the todo.txt vim plugin is triggered and shows the appropriate syntax highlighting.

https://github.com/freitass/todo.txt-vim

Fix importance being wrong when due date is a distant monday.

Close temporary file after saving to it

This can solve the problems with file handle being occupied by python
while editor is trying to save user changes from `topydo edit` on some
operating systems.

Potential fix for #141

Add HiddenTagFilter

Properly unmark items when resetting state

After introducing cache for TodoWidget objects, widgets highlighted with
'mark' action were not unmarked after 'reset' action and they reappeared
highlighted ("marked") after reverting `do` or `delete` commands.

This serves two purposes:

* Relative dates and progress colors are shown correctly on the next day
* Stale cached items get wiped at least once a day (for those who continiously
  run this mode)

When editing one or more todo items, some items may not have changed, therefore
having the exact same source text. The EditCommand still deletes the Todo
instance and creates a new one and puts it in the todo list. But the widget
cache only looked at the source text, found a widget from before the edit and
will use it. But the widget still has a reference to the old Todo instance.
When executing an action on it (e.g. mark it as complete), the TodoList doesn't
remember that todo item, which results in a crash.

Fixed by updating the reference to the latest Todo instance when the sources
are equal but the instances are not.

Having hundreds of todo items slows down the column UI quite a lot when doing
an update. An update basically throws away all widgets and creates them from
scratch. That is quite a waste when only one item has changed.

Instead, keep all widgets in a cache, retrievable by the todo's raw text. When
the raw text changes, a new widget is constructed.

Use the `h:1` tag to hide items from being listed

When topydo is run with colors, items without priority get an invalid
markup added. Only add markup when an item has actually a priority.

Bug found and fixed by @mruwek