Now on multi-core targets it only runs once, wasting less time.

Some boards have jumpers that control the reset vector, and forcing them
one way or another is more annoying than dealing with it in software.

Add interrupts to MulticoreRunHaltStepiTest.

Fixes #77.

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