When a race is found, info about the both racing insns is now shown
Defer setting of SW BPs if the target is initializing itself

Currently, it may be unsafe to track the execution of the target
while it performs its initialization. To be exact, it may be
unsafe to use kallsyms to resolve the names of the symbols (directly
or indirectly via %pS in printk(), via dump_stack(), etc.)
concurrently with the operations the module loader performs right
after the init function of the target returns.

In some kernel versions, the loader evicted the init-only symbols
from the symbol tables at that point and accessing the symbol tables
for the target module resulted in a race with unpredictable
consequences, including occasional crashes.

This commit makes sure that  we do not set the software BPs if the
target's initialization is still in progress. The delayed work to set
the BP is scheduled as usual, however, so the breakpoint should be set
eventually.

Unfortunately, this prevents RaceHound from detecting races during the
initialization of the target. In the future, this limitation should
be removed somehow.
Implemented repeated read checks

Similar to MS DataCollider, RaceHound now checks if the memory area
that is about to be accessed by an instruction, changes during the
delay. If it does, RaceHound reports a race.

Such repeated read checks are performed only if the HW BPs find no
races during the delay. If they do, they provide more information
about the races (they show both racing instructions rather than only
one), so they have a priority.