I have tested the provided functionality and found it to be, as expected, almost equivalent to the one proposed in #981. But since it reuses the existing FilteredTree, it is much cleaner and avoids duplication.

This implementation does still not perform well on our workspace. Once I stop typing, it takes several seconds to update the viewer. This seems to be because the generic filter logic of FilteredTree (and the used getChildren() implementation of the refactoring's content provider) is quite expensive to calculate. But since that is not an issue of newly added functionality but given by the implementation of FilteredTree, we can address that independently via improvements to FilteredTree afterwards.

I see one option for slightly improving the behavior when having a large workspace in which the filter update takes a long time: the debounce delay might be increased from FilterTree's default setting of 200ms, as that value is quite low and can easily be exceeded between two character inputs. The value could be increased to something like 500ms by overwriting FilteredTree.getRefreshJobDelay() to return an according value.

I would even be in favor of the changes without that modification, as this is a quick win for having a filter mechanism in the move refactoring. And no one is even forced to use it.