performance: filters, filternodes, & 34516

I've been looking at bug 34516, which is pretty bad - it means that
once you have more than 4 suggestions for a given type, you loose
the ability to see these suggestions.

It seems related to the new behavior in the tasklist that there is
-always- a filter in effect, even when the user hasn't added one;
the filter is a "null" filter - one without any conditions.

The problem is that once you have a filter, a different route
is taken in the TaskListView; it will use FilterNodes instead
of TaskNodes in the display.  The net result is that you end up
having to create twice as many nodes - for each task/suggestion
in the display, you have both a task node and a filter node!

This seems like unnecessary overhead. Is there a good reason it's
this way? Can we change it back? I also noticed that the preview
panel in the Filter dialog is gone - is the rationale that this
is just a customizer now? (The originally copied the design of
the filter dialog from the Mozilla mail filter dialog.)

The root cause of bug 34516 might be that our filter nodes
(TaskNode.FilterTaskNode) isn't handling dynamic changes from
Children.LEAF to Children(list) correctly.  So just changing the
filter behavior back won't really fix the bug since you'd still
have the problem once a filter is in effect (this is just theoretical
speculation).

-- Tor