- made GoroutineStacktrace a method of struct G
- made stacktrace a method of StackIterator
- renamed StackIterator to stackIterator
- factored out logic to obtain a stackIterator from a goroutine that's
used by both (*G).Stacktrace and by (*G).UserCurrent

Instead of returning an error when FDE of a frame can not be found,
just truncate the stack trace.

Fixes #462

Automatically sets a breakpoint on runtime.startpanic, the function
that gets called by runtime.dopanic when a panic is not recovered.

Implements #317

Caches the mapping of type names to offset in debug_info to speed up
variable evaluation.

BEFORE:
	BenchmarkArray-4         	     100	  13'238'441 ns/op	   0.62 MB/s
	BenchmarkArrayPointer-4  	     200	  10'044'093 ns/op	   0.87 MB/s
	BenchmarkMap-4           	    1000	   1'332'530 ns/op	   0.77 MB/s
	BenchmarkGoroutinesInfo-4	      10	 114'677'462 ns/op
	BenchmarkLocalVariables-4	    2000	   1'223'975 ns/op
AFTER:
	BenchmarkArray-4         	     200	   9'925'686 ns/op	   0.83 MB/s
	BenchmarkArrayPointer-4  	     100	  11'143'930 ns/op	   0.78 MB/s
	BenchmarkMap-4           	    2000	   1'302'520 ns/op	   0.79 MB/s
	BenchmarkGoroutinesInfo-4	      30	  35'079'549 ns/op
	BenchmarkLocalVariables-4	    1000	   1'137'299 ns/op

Note in particular the speedup of BenchmarkGoroutinesInfo, since
proc.(*Variable).parseG is a function we call a lot.

The go compiler changed and break statements no longer get compiled to
nothing when -N is passed:

https://go-review.googlesource.com/#/c/19848/
https://go-review.googlesource.com/#/c/19854/

Fixes #414

Moved the code in testvariables2 and testvariables4 into
testvariables3, renamed testvariables3 into testvariables2

Step disassembles the current instruction, if it is a CALL sets a
temp breakpoint inside the called function, after the prologue and
calls Continue.

Fixes #332

- Unlike FunctionEntryToFirstLine can skip the prologue on functions
that are defined on a single line, either because they weren't
formatted or because they were autogenerated
- Can skip the prologue on most functions when setting a breakpoint
with the filename:line syntax

Fixes #396

1. A running goroutine is by definition not parked waiting for a
chan recv
2. The FDE end address is intended to be exclusive, the code
interpreted as inclusive and sometimes ended up setting a breakpoint
on a function other than the current one.

Fixes #384

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

Backend only, no UI

Implements #120 (partial)

Fixes #198.

Temp breakpoints should be cleared even if a non-temp breakpoint is
triggered on the same goroutine that the temp breakpoints are set on.

Fixes #305

Prefetch the entire memory of structs and arrays and cache it instead
of issuing readMemory calls only when we get down to primitive types.
This reduces the number of system calls to ptrace that variables makes.

Improves performance in general, greatly improving it in some
particular cases (involving large structs).

Benchmarks without prefetching:
	BenchmarkArray-4         	      10	 132189944 ns/op	   0.06 MB/s
	BenchmarkArrayPointer-4  	       5	 202538503 ns/op	   0.04 MB/s
	BenchmarkMap-4           	     500	   3804336 ns/op	   0.27 MB/s
	BenchmarkGoroutinesInfo-4	      10	 126397104 ns/op
	BenchmarkLocalVariables-4	     500	   2494846 ns/op

Benchmarks with prefetching:
	BenchmarkArray-4         	     200	  10719087 ns/op	   0.76 MB/s
	BenchmarkArrayPointer-4  	     100	  11931326 ns/op	   0.73 MB/s
	BenchmarkMap-4           	    1000	   1466479 ns/op	   0.70 MB/s
	BenchmarkGoroutinesInfo-4	      10	 103407004 ns/op
	BenchmarkLocalVariables-4	    1000	   1530395 ns/op

Improvement factors:
	BenchmarkArray				12.33x
	BenchmarkArrayPointer		16.97x
	BenchmarkMap					 2.59x
	BenchmarkGoroutinesInfo		 1.22x
	BenchmarkLocalVariables		 1.63x

Fixes #341

Sometimes after PtraceSingleStep the thread does not advance of a
single instruction but is, instead, blocked immediately by a SIGSTOP
Made singleStep repeat the process until a SIGTRAP is observed.

Unsure where the SIGSTOP comes from.

Next sets its temporary breakpoints with the condition that they
must only activate on the current goroutine, and then calls Continue
When Continue encounters a temporary breakpoint it clears all
the breakpoint.

User visible changes: breakpoints that get hit while executing Next
are not ignored.

This commit does not implement full conditional breakpoints
functionality, the only condition that can be set is on the
goroutine id.

Fixes race conditions in Next affecting TestNextConcurrent.

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.

Fixes #325

recurseLevel value should not be reset when evaluating the contents
of an interface variable

Fixes #316

TestStacktraceGoroutine would occasionally fail due to race
conditions in the test itself

Supported operators:

- All (binary and unary) operators between basic types except <-,
++ and -- (includes & to take the address of an expression)
- Comparison operators between supported compound types
- Typecast of integer constants into pointer types
- struct members
- indexing of arrays, slices and strings
- slicing of arrays, slices and strings
- pointer dereferencing
- true, false and nil constants

Implements #116, #117 and #251

The new contents of api.Variable are documented in
proc/variables.go.

Implements #243

Instead of trying to be clever and make an 'educated guess' as to where
the flow of control may go next, simple do the more naive, yet correct,
approach of setting a breakpoint everywhere we can in the function and
seeing where we end up. On top of this we were already setting a
breakpoint at the return address and deferred functions, so that remains
the same.

This removes a lot of gnarly, hard to maintain code and takes all the
guesswork out of this command.

Fixes #281

This adds support for breakpoints statistics

Fixes #247

/proc/pid/stat needs more complex parsing

Fixes #239

Only use software breakpoints for now. The reasoning is because it
complicates the code without justification, and is only supported on
Linux. Eventually, once watchpoints are properly implemented we will
revive some of this code. Also, if it is ever necessary to actually set
a hw breakpoint we can revive that code as well.

All future versions of this code will include support for OSX before
being merged back in.

stack command: -full flag prints local variables and arguments of all the functions on the stack trace

Support multiple file / directory tables for multiple compilation units.

- added a type DebugLines that can hold number of DebugLineInfo
- added a supporting attribute to DebugLineInfo called 'Lookup' which is to be
used to quickly lookup if file exists in FileNames slice
- added supporting methods to lookup and return corresponding DebugLineInfo
- changed the debug_line parsing behavior to read all the available tables and
push them to DebugLines

- since Process.lineInfo is now a slice, it was breaking AllPCsBetween as well
- updated that function's definition to accept a new filename parameter to be
able to extract related DebugLineInfo
- updated calls to AllPCsBetween

- fixed tests that were broken due to attribute type change in Process
- updated _fixtures/cgotest program to include stdio.h, so that it updates
.debug_line header
- added a test to check 'next' in a cgo binary
- OSX - 1.4 does not support cgo, handle that in new testcase

This patch aims to improve how Delve tracks the current goroutine,
especially in very highly parallel programs. The main spirit of this
patch is to ensure that even in situations where the goroutine we care
about is not executing (common for len(g) > len(m)) we still end up back
on that goroutine as a result of executing the 'next' command.

We accomplish this by tracking our original goroutine id, and any time a
breakpoint is hit or a threads stops, we examine the stopped threads and
see if any are executing the goroutine we care about. If not, we set
'next' breakpoint for them again and continue them. This is done so that
one of those threads can eventually pick up the goroutine we care about
and begin executing it again.