Processing: OPC (re)connection in separate thread

A separate thread is used to monitor the OPC server connection (and reconnect if needed). Makes clients w/multiple server connections smoother...disconnected server(s) won't stall the whole show. Also starts up much faster, as all the server connections happen concurrently.

I've only made the change in the OPC.ino file for the first Processing example (grid24x8z_clouds) for your perusal, as I'm unsure whether others would find this change helpful vs detrimental (just in case there's CPU load or portability gas pains that I haven't foreseen). That example doesn't actually make multiple connections and won't see any performance difference, but shouldn't be any worse off in that regard either; theoretically nothing should change from the client's perspective, should still function. If it's any good, hope you might run with it in the future and spread it throughout the Processing examples.

Stuff gets interesting when you do this:

OPC opc[] = {
  new OPC(this, "candy1.local", 7890),
  new OPC(this, "candy2.local", 7890),
  new OPC(this, "candy3.local", 7890),
  new OPC(this, "candy4.local", 7890),
  new OPC(this, "candy5.local", 7890),
  new OPC(this, "candy6.local", 7890)
};

Where each is a battery-operated thing attached to a person, linked over WiFi. Problem was the whole system would choke and stall any time one (or more) went out of range or otherwise dropped the connection. The threaded scheme prevents this; servers can drop and reappear and the client (and all servers still connected) continue running smoothly regardless.