Remove the entirety of the StreamCapture Java machinery

• The Java side of the sample app contains a load of machinery to parse and analyse packets itself.
• To do this, it inserts itself into the data path between the actual TUN/TAP fd and onionmasq, reading and writing from that fd and giving another fd to onionmasq, which it writes to after it's done.
• This breaks a bunch of fundamental assumptions: the TUN/TAP fd will read() and write() whole packets, but the fd Java invents to give to onionmasq in its place doesn't work like this, resulting in all sorts of brokenness!
• We don't need this functionality to be in Java anyway; the Rust side can perform this kind of analysis and logging, if necessary in future.