Replace String+=String with StringBuffer inside tight network read loop.

From the commit message: *This results in much better performance. I see roughly 75sec vs 15min for a roughly 4MB rpc-reply from a real SRX device. Also CPU usage is much lower.*


I do have related question. When I found this problem (spending 100% of one core for 15min to deal with 4MB response from a device).  I originally wanted to fix it by hooking up session.getStdout() directly to a sax InputSource, because I figured that project probably handled reading efficiently. I figured you all might have tried that already and so I went looking in git log and found commit a327e923 by Paul that says: "fix to damn stream bug." What's the bug? Why didn't this work? Could it have been the Tee with logfile (which the current code isn't doing?) Or does Sax parse over-consume past the delimiter or something?