additionally fixes a bug when Detach is called on an exiting/exited thread: dbp.CurrentThread could point to a thread that has already been removed from dbp.Threads by trapWait which will lead to a nil pointer dereference caused proc.Process.clearBreakpoint getting nil from dbp.Threads[tid]

Fixes #154

On a thread that's leader of its group,
that is ptraced and that was survived by its children.

For hardware breakpoints we have to set them on every thread. It could
be the case that another thread is running. Stop it first, set the
breakpoint, then continue it.

Instead of maintaining two separate client / server implementations,
maintain only the more lightweight JSON-RPC service. The reasoning
behind the merging of the original HTTP service was ease of tooling, in
other words low barrier of entry for external clients (editor
integrations, etc...).

I believe the JSON-RPC solution still satisfies that constraint while
have the advantage of being a more lightweight solution. HTTP, while
highly supported in most modern languages, carries with it too many
features we would never take advantage of. The RPC architecture seems
a more natural approach.

The infrastructure set up during the initial HTTP service implementation
was leveraged in the JSON-RPC implementation, so if any of those
original authors are reading this commit message: thank you for that
work, it was not in vain even if though the original HTTP service is not
being removed.

Makes for more deterministic test runs.

Fixes #137

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

Finishes #63 #64