Multigdb support

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

The Gdb class now can handle connecting to more than one gdb. It
enumerates the harts across all connections, and when asked to select a
hart, it transparently sends future gdb commands to the correct
instance.

Multicore tests still have to be aware of some differences. The main one
is that when executing 'c' in RTOS mode, all harts resume, while in
multi-gdb mode only the current one resumes. Additionally, gdb doesn't
set breakpoints until 'c' is issued, so the hart where breakpoints are
set needs to be resumed before other harts might see them.

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