Improve filter menu for processes and tasks

[oliver-stoehr]

The menu filtering the process list and the task list should be improved to provide faster and easier filtering.
This proposal contains some layout and feature ideas to improve the filters for casual users as well as for power users. It could eventually eliminate the need for the "extended search" on a separate page.

• The filter content should be styled to provide a better understanding of the applied filters. Inspired by GitLab the individual filters should be optically separated from each other.
  
  This helps to identify the different parts of an filter and tell the filters apart.

• The filter input field should display a menu at the bottom border when the input is focused. This menu should provide rich information about available filter options.
  This menu should contain autocomplete options navigable by keyboard.
  

These options should be context sensitive to provide filter keys at first, then available operators and available filter values at last:

The menu should also contain all options like "show deactivated projects" and "show closed processes" currently located in the "possible actions" menu at the bottom of the process list. The "filter" menu at the bottom of the task list should also be consolidated into this new menu to have all filter options in one place.

[matthias-ronge]

In the development of 3.x, great importance was attached to not changing the search slot syntax so that saved filters continue to work. A lot of working time was put into this. Does this criterion still apply? (@andre-hohmann @subhhwendt ?)

Is it compatible with the suggestions presented here? From what I've read in the feature request, I would think the syntax is supposed to change (which I personally would like). But then how do we deal with existing saved filters? Are both syntaxes supported, or must the filters be converted?

[oliver-stoehr]

I think we should not change the existing syntax mainly used by power users. As you mentioned also the saved filters rely on this syntax.
I would rather implement another more interactive layer which would be internally translated to the existing syntax. So the old syntax could be still used, too.