Implemented "detour buffer" approach to setting of the software BPs

Before this commit, the software breakpoint that had triggered, was
removed before the monitored instruction was allowed to execute. This
was implemented this way to avoid using single-stepping and the tracing
flag exceptions because they sometimes did not play well with the
exceptions from the hardware breakpoints and resulted in system crashes.
However, this required to arm the software breakpoints somehow later to
track other executions of the same instruction. I used a timer to
implement that but that turned out very tricky to do right.

As RaceHound did not know when the monitored instruction had finished,
occasionally, it restored the software BP on it too early. This resulted
in a cascade of SW BP exceptions for a single (!) execution of the insn.
And each time the full processing was done, with delay, HW BPs, etc.
Pretty inefficient and time consuming. In addition, we might miss
executions of the insn that happened while the SW BP was not armed yet.

I have redesigned all this now.

Now the software breakpoints are always "armed" (until another set of
them is chosen by addr_work).

When a SW breakpoint triggers, it is handled the same way as before but
instead of removing the SW BP and passing control to the original insn,
RaceHound passes the control to the special "detour buffer" for that
instruction.

For each instruction of interest, a memory buffer is allocated from the
same memory area which is used to the code and data of the kernel
modules (module mapping space). The buffer contains a copy of the
instruction (properly relocated if needed) and a jump to the next insn
in the target module. Because it is allocated from the module mapping
space, it is guaranteed that the code of the target module is within
reach of a JMP near relative from that buffer even on x86-64.

I borrowed the idea from the implementation of Kprobes although it is
simpler in our case. We need to handle only a subset of the instructions
that Kprobes handle.

So the software breakpoint remains in place and we don't have to reset
it often. RaceHound no longer misses execution of the insns of interest
due to the SW BP not being reset yet. After the handling is done, the
insn executes normally in the detour buffer then the execution resumes
after the original insn as it should.

This is more safe and reliable that the previous approach.
Cosmetic changes: silenced more messages
Decreased the default delay to 5 jiffies (expressed in msecs)

The "detour buffer" mechanism currently used allows to avoid resetting
the software BPs often. This way, smaller delays should be enough to
detect races.

If 'delay' parameter is 0, the default value of jiffies_to_msecs(5) will
be used. In the experiments with the self-tests for RaceHound this
proved to be more than enough: twice as more races were then found in
the same or less amount of time than before.
Made SW BP update interval the parameter of the module

The set of the instructions software breakpoints are placed to will be
updated each 'bp_update_interval' seconds, possibly with random choice of
the insns among the available ones.

If this parameter is 0, the software breakpoints will remain where they
have been initially set. No randomization will take place.
Merge pull request #5 from euspectre/swbp_revisit

Redesigned handling of software BPs; tuned the delays