Documentation: hints for debugging

It would be nice to have some documentation with hints for debugging ACTS. There are a few specifics:
1. how to debug C++ with the Python examples
2. setting breakpoints after shared library loading
3. debug single-threaded if possible
4. often simpler to set breakpoints by source file location, rather than using heavily templated symbols.
5. `Debug` build can help, but default `RelWithDebInfo` still possible.

Here is an example I posted to Mattermost that deals with most of these issues. Maybe it would be a good starting point for the documentation. I only have experience of `gdb`. Andi suggested adding links to the different debuggers.

I didn't yet make a WiP PR, because I don't know where to put this. Should it go on a page of its own, or in a section elsewhere?

---

It's much easier to run with 1 thread. It's fine to use the Python examples. I edited to set `numThreads=1` in `acts.examples.Sequencer()`. Then ran `gdb`:
```
gdb --args python3 Examples/Scripts/Python/full_chain_itk.py
(gdb) b ActsExamples::Sequencer::run()
Function "ActsExamples::Sequencer::run()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ActsExamples::Sequencer::run()) pending.
```

After that, the log includes 8 messages like:
```
[Detaching after fork from child process 254497]
```
but those are mostly ROOT running various commands, so not a problem for debugging ACTS. It breaks here:
```
Breakpoint 1, ActsExamples::Sequencer::run (this=this@entry=0x3df39000) at Examples/Framework/src/Framework/Sequencer.cpp:242
242 Timepoint clockWallStart = Clock::now();
```

At this point, the program has loaded all the ACTS shared libraries, so you can now set breakpoints directly, not just pending ones. Of course if you want to debug the sequence setup, you'll have to set a breakpoint earlier. But for algorithm execution, `Sequencer::run()` is a good place to start.

It can be very difficult to set breakpoints using the fully qualified templated symbols, but easy to use the source line, eg.
```
(gdb) b EigenStepper.ipp:128
Breakpoint 2 at 0x7fffefa2522f: EigenStepper.ipp:128. (10 locations)
(gdb) c
```

The 10 locations are probably different template instantiations. This one breaks quite quickly, and shows the full (enormous) class name:
```
Breakpoint 2, Acts::EigenStepper >, Acts::detail::VoidAuctioneer>::step, Acts::Navigator>::State, ActsFatras::NoDecay, ActsFatras::InteractionList, ActsFatras::ChargedSelector, ActsFatras::EveryParticle, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::Min, ActsFatras::Min > >, (anonymous namespace)::HitSurfaceSelector> >, Acts::AbortList, ActsFatras::NoDecay, ActsFatras::InteractionList, ActsFatras::ChargedSelector, ActsFatras::EveryParticle, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::Min, ActsFatras::Min > >, (anonymous namespace)::HitSurfaceSelector>::ParticleNotAlive, Acts::EndOfWorldReached, Acts::PathLimitReached> > > >(Acts::Propagator >, Acts::detail::VoidAuctioneer>, Acts::Navigator>::State, ActsFatras::NoDecay, ActsFatras::InteractionList, ActsFatras::ChargedSelector, ActsFatras::EveryParticle, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::Min, ActsFatras::Min > >, (anonymous namespace)::HitSurfaceSelector> >, Acts::AbortList, ActsFatras::NoDecay, ActsFatras::InteractionList, ActsFatras::ChargedSelector, ActsFatras::EveryParticle, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::EveryParticle>, ActsFatras::ContinuousProcess, ActsFatras::Min, ActsFatras::Min > >, (anonymous namespace)::HitSurfaceSelector>::ParticleNotAlive, Acts::EndOfWorldReached, Acts::PathLimitReached> > > &) const (this=0x7f6ae8, state=...) at Core/include/Acts/Propagator/EigenStepper.ipp:197
197 while (true) {
```
In this case, it breaks at a different line from that selected, presumably due to inlining the `tryRungeKuttaStep` lambda. If this is a problem, it might help to compile with `-DCMAKE_BUILD_TYPE=Debug`, rather than the default `RelWithDebInfo`.

You can use `where` to see the full stack trace and all the other `gdb` commands.