Support more web3 versions

[Fang-]

This makes us compatible with contract object from the latest web3 version.

Otherwise, the .to of the generated transaction objects will be undefined, leading to "invalid opcode" errors when submitting to the blockchain.

But this newer web3.js version breaks tests! Something feels very buggy about the sendTransaction in latest web3.js. I think we need to manually add a .chainId to the transaction object, and after that it looks like we just run into web3/web3.js#2661.

I have confirmed that, just making the change in this commit, Bridge (which wants to use latest web3) works fine. Without it, it can't move past beta.33.

@jtobin would you say it's inadvisable to do a contract.address = (contract.address || contract._address) during contract initialization for now? I think that would allow us to stay compatible with both older and newer web3 versions, letting us keep tests at beta.33?

[jtobin]

Hmm. It does feel sort of dodgy to have the tests running using a different web3 version than does the library itself, even if it seems rather benign here.

/me thinks

[Fang-]

I didn't mean using different web3 versions for tests vs library code, but just straight-up supporting different web3 versions. This is what ends up happening in practice anyway: the reason I found out about this issue is I was working with a Bridge that uses web3 beta.52, which then gives contract objects that aren't 100% equivalent to the beta.33 ones azimuth-js assumes.

[jtobin]

Yeah ok, I think I see what you mean. Basically azimuth-js, library and tests, will use beta.33, but bridge will use beta.52.

On that note: it's probably a good idea to convert web3 to a so-called peer dependency of azimuth-js. Outside of the tests, azimuth-js doesn't actually use web3 at all -- it's essentially just a plugin for it. The peer dependency framework is supposedly designed for exactly this kind of thing.

With that in place, I think it's reasonable to use the contract.address || contract._address pattern and specify a broad/lenient set of web3 versions as the peer dependencies -- maybe 1.0.0-beta.x or something similar. And then when 1.0.0 lands we might want to strip the backwards-compatible mumbojumbo and just support 1.x or whatever.

I'm not sure if npm then permits one to configure tests to run with different dependency versions, but that would be awesome here too.

What say thee?

[jtobin]

(A note: I can handle the version/dependency munging.)

[Fang-]

I thought that's what "dev dependencies" were for? But you make it sound good, and you're willing to put in the work, so I'm down! (:

I'll force-push the desired pattern onto this PR.