Selection of problem matcher is not very intuitive when running a task

[michelkaporin]

Testing the following in #29442:

Task > Run Build Task: shows the list again with the task run last listed under recently used tasks. This time select a problem matcher: Enusre that problems are detected (2) and that the tasks.json file opens with a configuration like this...

I was presented with a list that contains several items that look similar but do not work the same way

To me Gulp TSC Problems [$gulp-tsc] and TypeScript problems [$tsc] problem matchers seemed semantically identical, so I picked up the first one just because I am using gulp task, and I needed to match TSC problems. It did not work, and only then I tried the second one, which worked and matched the problem.

If I wouldn't know what problem matchers do, I would not experience any difference whether I selected anything from the list or not.

Hence, two points:

1. If I select a problem matcher that does not find anything because it is wrong, I should have indication of this.
   Maybe 'Problems' tab can have a hint, pointing to problem matchers if a task was executed and no problems were detected? Other option is to echo information to the terminal that problem matcher did not find any problems. Otherwise it is very difficult to understand what was the impact of the selected problem matcher.
   Also having a badge with count of 'Problems found' on Problems tab in workbench pane would be beneficial, in order to see the result of problem matcher straight after running a task. Currently you have to move to 'Problems' tab to see problem count.
2. There should be a better way of semantic separation between those two tasks (and maybe any others). This is a difficult thing to do, and I cannot suggest anything at this time but we should be aware of it.

[dbaeumer]

Need to shift due to vacation.