Fixes to multiple issues encountered with JRuby

- Sublime Text 3 build 3054
- Ubuntu 13.10 64-bit amd64 cpu and graphics
- JRuby 1.7.6

Trying to run the pry repl via SublimeREPL with my setup gave me
numerous errors and problems. First, it would load with the error:

```ruby
before_session hook failed: Errno::EISDIR: Is a directory -
/home/eric/.config/sublime-text-3/Packages/SublimeREPL/config/Ruby
org/jruby/RubyIO.java:3738:in 'read'
(see _pry_.hooks.errors to debug)
[1] pry(main)>
```

This turned out to be tied to
[this line](https://github.com/wuub/SublimeREPL/blob/master/config/Ruby/pry_repl.rb#L72),
specifically the passed in self.

I'm unsure if passing in `self` here does anything, but removing it
doesn't seem to alter any behavior as far as I can tell.

Next, I was getting this error as soon as I tried typing anything:

```ruby
pry(main)> Exception in thread "RubyThread-7:
/home/eric/.config/sublime-text-3/Packages/SublimeREPL/config/Ruby/pry_repl.rb:1"
:java.lang.IllegalArgumentException
  at java.nio.ByteBuffer.allocate(ByteBuffer.java:334)
  at org.jruby.ext.socket.RubyBasicSocket.doReceive(RubyBasicSocket.
  java:452)
  at org.jruby.ext.socket.RubyBasicSocket.recv(RubyBasicSocket.java:160)
  at org.jruby.ext.socket.RubySocket.recvfrom(RubySocket.java:221)
  at home.eric.$_dot_config.sublime_minus_text_minus_3.Packages.
  SublimeREPL.config.Ruby.pry_repl.method__4$RUBY$read_netstring
  (/home/eric/.config/sublime-text-3/Packages/SublimeREPL/config/Ruby/
  pry_repl.rb:50)
  at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.
  java:618)
  at org.jruby.runtime.invokedynamic.InvocationLinker.
  invocationFallback(InvocationLinker.java:155)
  at home.eric.$_dot_config.sublime_minus_text_minus_3.Packages.
  SublimeREPL.config.Ruby.pry_repl.block_0$RUBY$__file__
  (/home/eric/.config/sublime-text-3/Packages/SublimeREPL/config/Ruby/
  pry_repl.rb:60)
  at home$eric$$_dot_config$sublime_minus_text_minus_3$Packages$
  SublimeREPL$config$Ruby$pry_repl$block_0$RUBY$__file__.call
  (home$eric$$_dot_config$sublime_minus_text_minus_3$Packages$
  SublimeREPL$config$Ruby$pry_repl$block_0$RUBY$__file__)
  at org.jruby.runtime.CompiledBlock19.yield(CompiledBlock19.java:159)
  at org.jruby.runtime.CompiledBlock19.call(CompiledBlock19.java:87)
  at org.jruby.runtime.Block.call(Block.java:101)
  at org.jruby.RubyProc.call(RubyProc.java:290)
  at org.jruby.RubyProc.call(RubyProc.java:228)
  at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:97)
  at java.lang.Thread.run(Thread.java:724)
  ```

It would freeze a lot while you tried to type this, and typing occured
in sputters and starts. Every few characters, that error would pop up
again. I tracked this down to
[pry_repl.rb Line 49](https://github.com/wuub/SublimeREPL/blob/master/config/Ruby/pry_repl.rb#L49)
where every few characters typed, `size` was for some reason a negative
 number.

No autocompletions were showing up, and in Sublime's python console,
the following error was being displayed from the plugin:

```
Traceback (most recent call last):
  File "/opt/sublime_text/sublime_plugin.py", line 358, in
  on_query_completions
    res = callback.on_query_completions(v, prefix, locations)
  File "/home/eric/.config/sublime-text-3/Packages/SublimeREPL/
  completions.py", line 40, in on_query_completions
    locations=locations)
  File "/home/eric/.config/sublime-text-3/Packages/SublimeREPL/repls/
  subprocess_repl.py", line 114, in autocomplete_completions
    locations=locations,
  File "/home/eric/.config/sublime-text-3/Packages/SublimeREPL/repls/
  autocomplete_server.py", line 55, in complete
    msg = read_netstring(self._cli_sock)
  File "/home/eric/.config/sublime-text-3/Packages/SublimeREPL/repls/
  autocomplete_server.py", line 11, in read_netstring
    byte = s.recv(1)
socket.timeout: timed out
```

Changing the `!=` to `>` stops the error message from Ruby showing up in
 the REPL, but not the stuttering character entry, lack of autocomplete
 nor the timing out of the python side of the socket.

Switching to the higher level TCPSocket class fixed this problem, the
rescue error handling seems to be necessary to prevent the python side
from timing out in the event something is typed which `pry` finds no
autocomplete for.