Append parent contexts

This works identically to append_parent_projects option. Code was
generated by simply `s/project/context/`

Give 'postpone' command possibility to work with multiple todos

topydo will report which todo IDs ('numbers') were invalid if user
supplied more than one on command-line. Error for operation on single
todo ID are reported as usual (for consistency with other commands sake
and because I'm lazy and don't want to fix 2 tests :P).

Allow multiple tasks to be prioritized at once

1. Shorter code for creating and populating 'todos' list
2. Merge IndexError and InvalidCommandArgument

@bram85: Thanks!

Fixes issue #5

When there is a todo in the list with an id: tag but no child todos,
that value could be reused when creating a new dependency between two
(unrelated) items.

This is because the value of the dangling parent todo is not present in
the dependency graph, but the function generating a new ID depended on
that.

Instead, simply iterate over all available todo items to check whether
the proposed value already exists somewhere.

When completing a command, show a warning when a 'rec' tag has an
invalid recurrence pattern.

Fixes issue #6.

Conflicts:
	topydo/lib/DoCommand.py

topydo may introduce some internal tags, such as 'id' and 'p' for
dependency tracking, and 'ical' for keeping track of unique ids when
outputting iCalendar files.

Add a pretty printer filter that prevents certain tags from displaying
in the 'ls' output. These tags can be configured with the 'hide_tags'
configuration option in the 'ls' section, a comma-separated list of
tags (default: id,p,ical). To always show all tags, leave an empty
value.

Reset the configuration on tearDown, instead of at startup.

This command is similar to the 'ls' subcommand, except that it prints
the selected todo items as an iCalendar file. This can be read by other
calendaring applications.

The IcalCommand, which inherits from this class, wants to use the same
view construction code, but needs a different implementation for
printing the view. Therefore these two things should be split.

There is no need for clients of printers to assume anything about the
format. In this case, the View class assumed that the printer would
return a list of strings, and then the view joined those entries. This
latter step is actually the responsibility of the printer, so move it
there.

Moreover, make print_todo of PrettyPrinter have the same signature as
the Printer class. Clients must use add_filter to specify any additional
filters when printing.

The Command class holds a PrettyPrinter instance (rather than a generic
printer). This means that add_filter is called, all future invocations
of print_todo will apply these filters. This is not always desired, so
in those cases a subcommand should instantiate its own printer (this
happens for instance at the DoCommand).

This allows for other printer implementations, where a printer is a
transformation from a Todo item to a string.

Fixes issue #1.

Move logic to retrieve the Command instance to separate method.

Also implement a 'help' subcommand, that either prints general help, or
when followed by a subcommand, prints the subcommand's help.

Fixes #4.