Also refactored code a bit, removed printing functions from proctl
package and inlined them into command.

FDEs previously were loaded into a red/black tree and searched. This is
significantly more expensive than a binary search over a slice. Not sure
what I was thinking using a red/black tree - this binary search
implementation is significantly more efficient.

This commit fixes a race condition between Delve and the runtime of the traced process. When a new thread is created in the traced process, Delve takes note of it and then continue both the new thread, and the thread that called clone. If Delve attempts to use data in `runtime.allm` before the new `m->procid` is set, errors occur. The errors are due to Delve assuming any m with a procid of 0 is the main thread of the process (due to how theGo runtime allocates M's, only `clone`d threads have procid properly set. This causes certain events (like `next`) to happen twice to the main thread, because 2 m's in `runtime.allm` have a `procid` of 0, and also causes various other issues that prevent proper thread coordination from Delve.

Fixes #43

As of go version 1.4 the standard library syscall package is "locked
down" and code outside of the standard library is recommended to migrate
to the go.sys subrepository.

Reference: https://golang.org/s/go1.4-syscall

Currently there is no need for the other items in the ProcessStatus
struct, we really only care if the process is not running, so we can
avoid sending signals to it.

Currently only works for amd64 processors.

Handle SIGINT by stopping the traced program and then displaying a
prompt to the user for commands. If the traced process is not running,
this is a noop.

Closes #30

This remove reliance on the procfs for figuring out what threads are
already active when we attach to a running process. The allm linked list
will be present to matter what OS we're on, whereas procfs will not be
present everywhere.

This is the first in a series of steps to support more platforms.

Remove any assumption that a wait syscall on a thread id after a
continue will return. Any time we continue a thread, wait for activity
from any thread, because the scheduler may well have switched contexts
on us due to syscall entrace, channel op, etc...

There are several more things to be done here including:

* Potential tracking of goroutine id as we jump around to thread
  contexts.
* Potential of selectively choosing threads to operate on based on the
  internal M data structures, ensuring that our M has an active G.

This commit partially fixes #23 and #24, however there are still some
random hangs that happen and need to be ironed out.

Wrap syscall.Wait4 and cleanup a few coordination issues.

There are still some issues here where background threads are left
sleeping. This could potentially cause weird issues. There are a few
more things I have planned to cleanup thread coordination issues.