Fncall.go was written with the assumption that the object returned by
proc.Thread.Registers does not change after we call
proc.Thread.SetPC/etc.

This is true for the native backend but not for gdbserial. I had
anticipated this problem and introduced the Save/SavedRegisters
mechanism during the first implementation of fncall.go but that's
insufficient.

Instead:

1. clarify that the object returned by proc.Thread.Registers could
   change when the CPU registers are modified.
2. add a Copy method to Registers that returns a copy of the registers
   that are guaranteed not to change when the CPU registers change.
3. remove the Save/SavedRegisters mechanism.

This solution leaves us the option, in the future, to cache the output
of proc.(Thread).Registers, avoiding a system call every time it's
called.

Implements the function call injection protocol introduced in go 1.11
by https://go-review.googlesource.com/c/go/+/109699.

This is only the basic support, see TODO comments in pkg/proc/fncall.go
for a list of missing features.

Updates #119

Windows and macOS aren't using this field so move it to the os-specific
thread struct and remove it from everything except linux.

If a breakpoint is hit close to process death on a thread that isn't
the group leader the process could die while we are trying to stop it.

This can be easily reproduced by having the goroutine that's executing
main.main (which will almost always run on the thread group leader)
wait for a second goroutine before exiting, then setting a breakpoint
on the second goroutine and stepping through it (see TestIssue1101 in
proc_test.go).

When stepping over the return instruction of main.f the deferred
wg.Done() call will be executed which will cause the main goroutine to
resume and proceed to exit. Both the temporary breakpoint on wg.Done
and the temporary breakpoint on the return address of main.f will be in
close proximity to main.main calling os.Exit() and causing the death of
the thread group leader.

Under these circumstances the call to native.(*Thread).waitFast in
native.(*Thread).halt can hang forever due to a bug similar to
https://sourceware.org/bugzilla/show_bug.cgi?id=12702 (see comment in
native.(*Thread).wait for an explanation).

Replacing waitFast with a normal wait work in most circumstances,
however, besides the performance hit, it looks like in this
circumstances trapWait sometimes receives a spurious SIGTRAP on the
dying group leader which would cause the subsequent call to wait in
halt to accidentally reap the process without noting that it did exit.

Instead this patch removes the call to wait from halt and instead calls
trapWait in a loop in setCurrentBreakpoints until all threads are set
to running=false. This is also a better fix than the workaround to
ESRCH error while setting current breakpoints implemented in 94b50d.

Fixes #1101

Fixes #809

- move native backend to pkg/proc/native
- move gdbserver backend to pkg/proc/gdbserial
- move core dumps backend to pkg/proc/core

* proc: refactor BinaryInfo part of proc.Process to own type

The data structures and associated code used by proc.Process
to implement target.BinaryInfo will also be useful to support a
backend for examining core dumps, split this part of proc.Process
to a different type.

* proc: compile support for all executable formats unconditionally

So far we only compiled in support for loading the executable format
supported by the host operating system.
Once support for core files is introduced it is however useful to
support loading in all executable formats, there is no reason why it
shouldn't be possible to examine a linux coredump on windows, or
viceversa.

* proc: bugfix: do not resume threads on detach if killing

* Replace BinaryInfo interface with BinInfo() method returning proc.BinaryInfo

* proc: changed windows backend to deal with simultaneous breakpoints

* bugfix: forgot to add windowsPrologue3 to the prologues list in e4c7df14

* Tolerate errors returned by Stacktrace in TestStacktraceGoroutine.

* bugfix: proc: propagate debug events we don't cause back to the target process

Fixes: #594

* proc: fixed TestStepConcurrentPtr

Implementation of nextInProgress was wrong.

Fixes #414

Unrelated to conversion, I have also changed (*Thread).readMemory
to return only first count bytes of memory just as advised
by ReadProcessMemory.

Fixes #409
Fixes #412
Fixes #416

Fixes #198.