Klever

When implementing #9035 several times I noticed strange hang ups when inspecting VTG plugin for callbacks in dynamics. Indeed, at the moment none of VTG plugins define any callback, so this step is redundant at all. Moreover, a mechanism for getting such the callbacks has a very complicated infrastructure around it, so, getting rid of these callbacks will allow to get rid of that infrastructure in addition and the code will be more straightforward.

A long ago VTG plugin callbacks were implemented to support some backward advices for a build and source analysis. For instance, if for checking a given rule specification it is necessary to get Linux kernel functions that can sleep or return just non-positive integer values (negative ones are for representing errors and 0 is for success), then it would be better to perform corresponding analysis ahead and do not repeat it for each particular verification object. Times change. Now the build as well as source analysis moves out from Klever to Clade. This means that likely everything required for verification will be obtained ahead unconditionally - this is the most straightforward and efficient way to follow. Nevertheless, sometimes there can be deviations. For instance, if one will need to perform and to store in a Clade base information from some additional source analysis that was not performed ahead. Of course, nobody forbids to run a corresponding Clade tool outside of Klever, but usually users are lazy, so, let's hide the "magic" within appropriate VTG plugins. But even in this case there is little sense in VTG plugin callbacks as they can refer to required Clade tools themselves passing necessary arguments, in particular source query aspect files. The only requirement for Clade tools is that they should not execute the same things several times especially in parallel. That can be easily avoided by appropriate internal specific locks.