Just to hammer on anything at once, and hopefully catch weird
interactions if they exist.

Proper multicore support for debug tests

When compiling, define the number of harts. This means we only need to
allocate a lot of stack if there are a lot of harts.

On overloaded systems, when executing compare-sections, otherwise gdb
might hit a timeout and the compare-sections code doesn't deal with it.
(You get an error message complaining that 130 is not a valid hex
digit.)

Targets now contain an array of harts. When running a regular test, one
hart is selected to run the test on while the remaining harts are parked
in a safe infinite loop.

There's currently only one test that tests multicore behavior, but there
could be more.

The infrastructure should be able to support heterogeneous multicore,
but I don't have a target like that to test with.

When a machine is very loaded, otherwise it could happen that we send
the interrupt before the resume has actually happened.

Inform GCC that "sfence.vma" clobbers memory

I don't exactly understand why it has to be the way it is, but I just
want it to work.

Also fix a pylint complaint.

Debug: Usability Features

For one of the test addresses, use the highest possible one to ensure
that OpenOCD isn't secretly reading/writing more words than requested.

Instead, just give up on making the log files altogether now. Since
gdbserver.py makes its own log files it's not as necessary in any case.

This is yet another commit in an attempt to get the riscv-tools build to
actually fail if these tests fail.

Testing is a separate step.

Also fix Issue #64 by adding src_dir to the path to the targets file.

This would have prevented some bugs I committed earlier.