* service/rpccommon: fixed typo

* proc: test parseG while target is in runtime.deferreturn

runtime.deferreturn will change the value of curg._defer.fn in such a
way that if the target is stopped at just the right instruction it
may crash an incorrect implementation of parseG

* proc/stack: handle stack barriers correctly

Correctly handle stack barriers insterted during garbage collection.

Adds ability to load x87, SSE and AVX registers.

Fixes #666

See: https://github.com/golang/go/issues/16180

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

Fix typo.

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

Three locations are returned for goroutines: its current location,
its current location excluding unexported runtime functions and
the location of its go instruction.
The command 'goroutines' takes a new parameter to select which
location to print (defaulting to current location w/o runtime)

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

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.

Fixes a code path where stacktrace returns < 2 locations and
thread.ReturnAddress would panic. Now returns an error.

Major source cleanup, still not finished. Removes gross control flow.

* Cleanup comments
* Cleanup naming in certain instances
* Modify stacktrace to return current location

Finishes #63 #64

Process is an incorrect name for the DebuggedProcess struct that the
thread is "a part" of. Also, no need to export that field.

* Properly find next source line for goroutines blocked in chanrecv
* Refactor breakpoint clearing
* Refactor temp breakpoint setting