…ed date

For activity in cmdline: `some activity` (without date and time)
- checked incrementing and decrementing day
- checked date picker
- checked date picker set to one date and cmdline on another date (cmdline has higher priority)

This fixes projecthamster#627 Adding activities in retrospect is very hard.

… selected date

… selected date

… selected date

This was unused.

The `extract_search` helper function was passed the text and parsed a
Fact from that. However, all places calling this function already parsed
that same text, so easier to just pass the parsed Fact rather than the
text.

Inside CmdLineEntry, the text was previously parsed without specifying a
default_day, causing the (start) date of that parsed fact to be the
current date.

This was mostly harmless, since these parsed facts are
only used to generate completions (the actual fact to be saved is
parsed by CustomFactController, which does apply the right date).

However, in some cases, this caused suggestions to look slightly weird
(such as when editing a fact with a start time before today and without
end time, the "stop now" entry would show an explicit date, because the
serialization *did* use default_day). By using the default_day also for
parsing, the CmdLineEntry always has the right idea about the fact that
it is creating, which removes these small weirdnesses.

This ensures that `self.date` remains correct, which indirectly makes
sure the "dayline" at the top of the window is updated, and ensures that
the cmdline also uses the right date for subsequent serialization and
completions.