Also don't try to do anything after such error occurs so we don't
trigger another crash if default_command is assinged to some alias.

Hopefully finaly fixes #107

Provide adequate "mono" palette for column ui

Focused items are now properly highlighted when colors are set to 0 and
marked items are made bold and underlined.

Without any colors, TopydoString doesn't have any colors set resulting
in an empty markup item. That made the urwid library trip.

Also, disable colors when not connected to a TTY. Before, when the
configuration file configured 256 colors, it would be used whether
regardless of being connected to a TTY.

This is achieved using abstract colors for projects, contexts, etc.. The
Color filter for the pretty printer has no knowledge of colors, it just
marks a certain text as 'project color'. All this information is stored
in the TopydoString. The CLI will convert the colored parts in the
string with the corresponding ANSI codes, the column UI will convert the
string to an appropriate markup for the Text widget.

Also, palette items are now specified using an enum-like class
(PaletteItem) to reduce hidden dependencies of the palette item names.

Moreover, ConsoleWidget is now a urwid.Pile with Text widgets, instead
of one single Text widget with all text. This also allows for doing
operations on lines in the output in the future (mark a line and hit
complete, for instance).

PrettyPrinter no longer outputs a string, but a TopydoString in case of a
single todo item, or a list of TopydoStrings that may contain color
information. Those who read the PrettyPrinter output should convert it to a
string that can be displayed.

TopydoString is a string descendent that maintains information where
colors should be applied in a string. A user interface can pass a
function that transforms a color to a color representation that is
relevant there. That way, the topydo library does not make any
assumptions anymore on where colors should be applied.

Use special color-palette entry for 'marked' items

This improves readability. Marked items look now differently from the
focused one.

Use all configurable colors in TodoWidget

Use business days recurrence in column ui

Previously only priority color was rendered. Now all contexts, projects,
links and metadata should show theirs colors.

Execute commands on multiple items + repeat command

This required to slightly change UIApplication._execute_handler so it
accepts now also a todo id as an argument.

Introduce proper TodoWidget.mark and TodoWidget.unmark public methods so
we don't have to expose _markup.

Use rahter 'mark' and 'marked' instead of 'pending' here and try to use
verb-based function names wherever possible.

Also some minor code-style changes suggested by @bram85.

Repeats last topydo command called from within `TodoListWidget.keypress`
(won't repeat commands called from cli).

Default mapping: '.'

It does 2 things:

1. Clears marked statuses for todo items
2. Resets keystates in all columns

Conflicts:
	README.md
	test/test_list_format.py
	topydo/cli/CLIApplicationBase.py
	topydo/lib/Config.py
	topydo/lib/Utils.py

Don't crash on shlex.split error

1. 'm' can be reconfigured to any other key (action: 'mark').
2. Using 'mark' on already marked todo item will unmark it.
3. 'esc' key will clear whole selection.
4. Command will be executed on **all** marked items in **all** columns.

Show some meaningful error messages instead.

Fixes #107

Add recurrence and postponing by business days

Inspired and also supported by simpletask[1].

`rec:1b` will recur after 1 business day and `rec:5b` after one full
business week. Negative values are supported.

This feature doesn't of course take holidays into account.

[1]: https://github.com/mpcjanssen/simpletask-android/blob/master/src/main/assets/index.en.md

However, this still doesn't work because the configuration is overridden
due to the color=0 hack. Flags like -t and -d will work as soon as the
color setting override is gone.

Thanks to @mruwek for the reminder.

Also removed some unreachable branches from the code.

The color functions now return a neutral/default color when
empty/garbage colors are entered in the configuration file.

This addresses issues #69 and #70.

The -C flag takes 0, 1, 16, 256, auto, yes, true, no, false as possible
values.

If auto, then colors are enabled unless the output is not connected to a
TTY and is likely not to understand ANSI escape codes. 'auto' is the
default value.

The config().colors() function either returns 0, 16 or 256 for the
possible colors that can be displayed.

These values are also recognized by the colors option in the
configuration file.

This fixes issue #111.

This color class abstracts away all the possible representations of a
color in various UIs. These are color objects:

Color(9)              # red
Color('red')          # red
Color(196)            # red
Color('NEUTRAL')      # neutral (resets attributes)
Color()               # no effect

The configuration stores Color objects now, code that requires colors
doesn't have to worry about integer representations of colors.

One semantic change: when an empty color is passed as a priority color,
it will resort to an empty color instead of the neutral color. In
practice this should have the same visual effect. Test case
test_priority_color4 is adapted for this.

This commit is the result after an initial refactoring of the color code
(squashed its history into this one). @mruwek also contributed to this
refactoring, thanks for the help and the ideas to get to this point.