cleaned up zmq_proxy() for travis

cleaning up my earlier PR by attempting to fix travis tests. note that libzmq API support for proxying xpub/xsub came out in v3. 

The function in JS now supports API characteristics of native zmq_proxy() function. So this new method would go something like:

```js
var zmq = require('zmq');

var xsub = zmq.socket('xsub');
xsub.bindSync('tcp://*:5556');

var xpub = zmq.socket('xpub');
xpub.bindSync('tcp://*:5555');

var pub = zmq.socket('pub');
pub.bindSync('tcp://*:5554');

zmq.proxy(xpub, xsub, pub);
```

Written with support for a few useful socket combos `pull/push`, `xpub/xsub`, `router-dealer` and we could always just drop in support for other combos like I was thinking maybe proxying `pair/pair`.

also it throws an error when you don't get xpub/xsub supported socket order right. Strictly following the libzmq API would just fail silently in this case, I think, so that may slightly diverge from its native library counterpart.
the thought crossed my mind, args could be limitless. but args in this forwarded message array are distinct from messages initiated over the wire. 

So when our messages contain limitless pieces, these pieces all belong to the `message` frame.

`id` and `delimiter` frames are for advanced handling across specific routing schemes.

libzmq builds this unusual envelope signature automatically under the binding. Since it's up to us to forward the complete envelope during proxying, I think here's a good reason to have a `zmq.proxy()` function, so we don't have to think about it.