Add test category filter

[rowo360]

In this PR I propose a solution for filtering tests by category for issue #1147.
Many changes affect UI elements so I am adding screenshots and also a textual description of the proposal here. But it may be helpful to try out the feature in addition to the code review. Just to get an impression of the user interface.

Screenshots:
New toolbar item:

Category filter dialog:

Here is a feature list:

• There's a new DropDown button in the filter toolbar
• Clicking on this button opens a new dialog.
• The dialog displays all test categories
• The dialog is a non-modal dialog which is displayed on top of the main form.
  I assume that we will discuss this idea. But for me, it was the most user-friendly approach which I liked best.
  The user can select test categories, view the filtering result in the tree immediately, navigate through the tree nodes (expand/collapse) and continue to select test categories right away without reopening a dialog or menu. (For example: If the previous selection was not appropriate)
• Therefore there are those two buttons 'Apply' and 'Apply+Close' to support this non-modal dialog behavior
• The dialog can be resized - I expect that we will have projects with a large number of categories or long names for test categories. Therefore, a fixed size would eventually lead to complaints later on.
• There are two buttons 'Select all' and 'Clear' to edit all categories at once
• Additional there's a 'search' TextBox for quick navigation
• The dialog is placed below the DropDown button by befault. However, the position and size of the dialog are saved and applied the next time the dialog is opened (not saved in the settings, but only for the session)
• If any category filter is active, the DropDown button in the filter toolbar is displayed in bold to give an indication that the filter is active.

[rowo360]

My proposed solution is certainly not the only option. But as I said, I liked it best. These are other variants that I have tried but abandoned. I'm describing them now for completeness:

I started using a simple DropDownMenu containing the test categories. I even managed to place these 'Select all' and 'Clear' Buttons inside that menu. But it looked a bit strange and overall it wasn't user-friendly. So I dropped this idea.
Here's a screenshot of that approach (not containing the 'Select all' and 'clear' button)

My second idea was to replace the DropDownMenu with a form which contain some controls. In contrast to my final proposal this form is displayed without a Titlebar and gets closed automatically when clicked outside. So, it behaves more like a DropDownMenu. If I remember correctly, I was also able to implement the resize functionality. But here and there a few tricks had to be used to adapt the behavior of the underlying form to the behavior of a drop-down menu. Which I almost managed to achieve, but not completely. Another observation was that you had to open the menu again and again when working with test categories - which felt exhausting.
Therefore the idea of using a real dialog came up at this point. The implementation was even easier and straight forward.
Nonetheless here's a faked screenshot of that approach:

[rowo360]

I'm not sure about the term 'Filter by category' in the toolbar.

Is it more appropriate to use only 'Category' or 'By category'?

[rowo360]

I added also some new files to the Elements folder - I already take care to place them into the appropriate subfolders and to update the new Readme.md file.
But maybe you can review especially the names of these new classes and interfaces:
ICategoryFilterSelection and ToolStripCategoryFilterButton
I renamed them already several times to reflect that these are files dedicated to the category filter functionality. I doubt that they can be reused by any other feature...
Do they correspond to the expected naming scheme?

[rowo360]

And may I draw your attention to the new class TextBoxElement in folder Elements/ControlElements?
This class is pretty identical to class ToolStripTextBoxElement beside the fact that it's derived from class ControlElement.
Is this accepted? Or should we extract the common parts to a separate class (independent from ControlElement and ToolStripElement)