Minor issue: restructure BridgeKernels class

[valassi]

While working on the new strategy for FPEs #831, I would like to print out from C++ at the end the list of FPEs that signalled.

This is a bit awkward now because the class structure must be cleaned up. There are logically some singletons like CPPProcess, but the implementation is not that of a singleton (see #356). Essentially, it would be nice to add the FPE dump in the destructor of a class that we always use.

For the moment, I added this to MatrixElementKernelBase destructor. Surprise however, the fpe dump happens more than once in some cases, showing that more than one MEKB exists.

One obvious example is check.exe when called with the --bridge option. This is the only feature that uses the BridgeKernels classes. There is clearly something to be fixed here, as there are two MEKB: the BridgeKernel derives from a MEKB, but then it also contains a bridge that creates a MEKB itself, and there are two. Not a real problem, especially for madevent use, but a low priority issue to be cleaned up at some point...

(By the way, also runTest.exe prints the fpe dump more than once, also to be understood, but probably depends on other reasons)

[valassi]

(By the way, also runTest.exe prints the fpe dump more than once, also to be understood, but probably depends on other reasons)

This is fixed in PR #832. There was one MatrixElementKernels instance per iteration (once in every signamKin call) in MadgrahTest.h, now a single instance is used for all test iterations

[valassi]

For the moment, I added this to MatrixElementKernelBase destructor. Surprise however, the fpe dump happens more than once in some cases, showing that more than one MEKB exists.

This is also fixed. I moved the printout to the destructor of MatrixElementKernelHost/Device, removing it from MatrixElementKernelBase (which is also a base class of BridgeKernels). It fixes the printouts, but not the fact that BridgeKernels should be restructured. Low priority anyway.