Fixes hang on Jedi connects that timed out

I haven't narrowed down exactly why this happened, yet, however after
having trouble with ST for ~3 days now, have found a fix.

After starting ST3, which resumed a session with about 6 previously open
windows, Anaconda would register a local handler, and a few seconds
later called `server_is_active` on the worker for it. At that time, ST3
would hang.

As it turns out, Anaconda couldn't connect to the worker it set up, but
didn't use a socket timeout for the `server_is_active` check. Without
specifying one, this could cause ST3 on OSX to hang for 5 minutes.

Once ST responded after 5mins, the expected 'timed out' exception
appeared in the console. Seemed to happen only once at startup no matter
how many windows I had open in the session.

At first, to temporarily get around this, I renamed my
`~/Library/Caches/Jedi` folder between ST runs to get it to build a
fresh caches folder. So something in there created/managed by Jedi seems
to be the root cause.

Ultimately, I was able to fix this altogether on the Anaconda side with
this addition of a 0.5sec timeout on the socket that
`BaseWorker.server_is_active` creates.

`BaseWorker.server_is_healthy` already uses the same 0.5sec timeout, so
the assumption of 0.5 seemed safe for checking whether it's simply
active.
Merge pull request #113 from briancline/local-jedi-timeout-fix

Fixes hang on Jedi connects that timed out
Merge pull request #114 from bhappyz/master

Feature: Adding a [Set Python Interpreter] command
Import new AnacondaSetPythonInterpreter class

AnacondaSetPythonInterpreter is present in __all__ list but not imported.
Merge pull request #115 from ihuston/patch-1

Import new AnacondaSetPythonInterpreter class
Merge pull request #1 from DamnWidget/master

update