Adding and looking up items based on a hash table is incredibly
fast, so it's vital for startup, however at runtime we want
to prepend which invalidates the contents of the hash table. So
now we use the hash based lookup only for frozen operation,
which is used at startup and has to be fast, but manual string
comparisons are used at runtime.
This resolves various indirections, and since we are always
using the action anyway, we finally move all logic to one
place. There should be room for optimizations now.
Incidentally this also keeps the completion intact if
the entry needs to be recreated.
For the moment, a define in the code decides whether items
are sorted based on when they were added or how often
a page was visited. The 'visits' property and respective
database column is unused (we keep it for compatibility).
It turns out it's enough to store that information in
the tree model.
The visit based sorting is not enabled because it is
simply delaying startup incredibly. It will have to be
decided whether to introduce a preference, or always use
a visited based sorting once the startup delay is fixed.
History items are also deleted from the tree model now
if they are too old, according to the preference.
Property name localization is only useful if the
strings are meant to be used in a user interface,
such as is the case with WebSettings, or for
graphical interface builders, which are not of
our concern, since we don't use Glade and friends
and nobody else is going to use our widgets.
In short, make translation work much easier.
