* tests: update to cope with go1.7 SSA compiler

* de-vendored golang.org/x/debug/dwarf

We need our own tweaked version

* dwarf/debug/dwarf: always use the entry's name attribute

Using the name attribute leads to better type names as well as fixes
inconsistencies between 1.5, 1.6 and 1.7.

* proc: Updated loadInterface to work with go1.7

go1.7 changed the internal representation of types, removing the string
field from runtime._type.
Updated loadInterface to use the new str field.

This patch modifies the `step` command to step to the next source line,
stepping into any function encountered along the way.

Fixes #360

Typedefs that resolve to slices are not recorded in DWARF as typedefs
but instead as structs in a way that there is no way to know they
are really slices using debug/dwarf.
Using golang.org/x/debug/dwarf instead this problem is solved and
as a bonus some types are printed with a nicer names: (struct string
→ string, struct []int → []int, etc)

 Fixes #356 and #293

Fixes #198.

resume loops in continueOnce moved to a OS specific resume function,
this makes the problem easier to deal with and seems to be more
appropriate to a windows port given what transpired from discussion
of Pull Request #276

Fixes #262

Breakpoints are skipped either because:
1. when multiple breakpoints are hit simultaneously only one is
processed
2. a thread hits a breakpoint while another thread is being
singlestepped over the breakpoint.

Additionally fixed a race condition between Continue and tracee
termination.

Prevents a lot of goroutines hanging around, especially when running
tests.

/proc/pid/stat needs more complex parsing

Fixes #239

Fixes a bug on OSX where, if the debugged process spawned a child, when
that process received a SIGCHLD it would cause Delve to hang.

Fixes #197

We don't care, at the process level, whether or not we're single
stepping. That state is really only relevant at the thread level.

Instead of fighting against the normal flow, just signal a SIGTRAP and
let the existing flow handle it, as long as we set the halt flag
correctly the system should halt.

Fixes #154

On a thread that's leader of its group,
that is ptraced and that was survived by its children.

Previously either the terminal client or the debugger service would
either lock main goroutine to a thread or provide a locked goroutine to
run _all_ DebuggedProcess functions in. This is unnecessary because only
ptrace functions need to be run from the same thread that originated the
PT_ATTACH request.

Here we use a specific thread-locked goroutine to service any ptrace
request. That goroutine is also responsible for the initial spawning /
attaching of the process, since it must be responsible for the PT_ATTACH
request.