This function was broken for a very long time until the changes in this
PR fixed it. However I do not think it is desirable to be catapulted
into some other goroutine by 'next' just because that other goroutine
happened to receive a message on a channel.

This feature should be implemented by a new command, not next.

Previously Step would step through the goroutine associated with
CurrentThread if SelectedGoroutine was parked

Previously Next would step through the goroutine associated with
CurrentThread if SelectedGoroutine was parked

Also fixes a bug with proc.(*Process).StepInto where StepInto could
switch to a different goroutine.

* 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.

Fixes #554

Fix typo.

* proc: bugfix: StepInto can not function when temp bps exist

* terminal,service: auto-continue during next and step

Make dlv call continue automatically when a breakpoint is hit on a
different goroutine during a next or step operation.
Added API hooks to implement the other solution to this problem (cancel
the next/step operation if a different breakpoint is hit).

Fixes #387

If we are unable to correctly guess how a type is serialized in
debug_info let the user specify it directly.

Workaround for #455

* service/api: Removed unused fields of service/api.Function

* proc/eval: Set return variable name to input expression

* all: fine-grained control of loadValue for better variable printing

Makes proc.(*Variable).loadValue loading parameters configurable
through one extra argument of type LoadConfig.
This interface is also exposed through the API so clients can control
how much of a variable delve should read.

* proc: add tests for command-line arguments

adds tests to make sure command-line arguments are passed to Launch() properly

* proc_windows: pass command-line arguments to CreateProcess()

build command-line arguments according to how the standard library does it and pass the command line along to the actual syscall on Windows.

see discussion in #479

* proc: better testing of cmd-line arguments

* proc_windows: fix a possible error-case with passing just 1 argument

previously, the command line pointer passed to sys.CreateProcess was empty, if we had 0 parameters (len(cmd) == 1, as cmd[0] is the executable, so no cmdlineGo would be created, while with any argument it would as len(cmd) > 1). This might cause problems down the road, so make sure we include the command line every time, even if it seems to work without.

* proc: improve testing of command-line arguments

test that arguments with spaces are passed on correctly and DRY failure/success condition checking in the args test

proc.(*Thread).Scope fails if we can find a FDE but PCToLine returns
nothing

- 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

On linux kernel 2.6.x, the Trace/Stop status is 'T'

Fixes #209

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/

Lists all the types defined in the debugged program.

Fixes #414

Fixes #419 (partial)

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

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

Implements #109 and #120

Implements #368