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

Fixes #360

Backend only, no UI

Implements #120 (partial)

Fixes #198.

Location specifiers starting with '*' can be followed by any
expression supported by the evaluator.
The expression should evaluate to either an integer (which will be
interpreted as an address) or to a function pointer (which will be
dereferenced to get the function's entry point).

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.

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

Implements #243

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

set <variable name> <value>

Use proc.(*Process).FindGoroutine in proc.(*Process).SwitchGoroutine and
debugger.(*Debugger).Stacktrace. That method did not exist when those
were originally written.

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

Breakpoints, tracepoints, etc.. take a location spec as input. This
patch improves the expressiveness of that API. It allows:

* Breakpoint at line
* Breakpoint at function (handling package / receiver smoothing)
* Breakpoint at address
* Breakpoint at file:line
* Setting breakpoint based off regexp

Fixes #188

Allows a user to execute `dlv trace [regexp]` and Delve will execute the
program and output information on functions matching [regexp].

Fixes #95

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

Fixes #154

s/Break/SetBreakpoint/
s/Clear/ClearBreakpoint/
s/BreakByLocation/SetBreakpointByLocation/

Finishes #63 #64

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.

Hardware breakpoints are by definition architecture dependant. Move them
off the DebuggedProcess struct and onto the associated arch struct.

Prevents leaving around a bunch of zombie processes