Use bitcore-lib as a peerDependency

[CaptEmulation]

One wrinkle to using the bitcore stack is the obvious need to have a singleton bitcore-lib. The bitcoin-lib package hosts the bitcoind library and there are good reasons to not wanting to have multiple bitcoind instances running on the same machine.

However, I am not a fan of the runtime check and would rather have all packages be declaring bitcoin-lib in peerDependencies. This way the enclosing package can specify whatever version of bitcoin-lib it wants and npm will inform user if there is an unmet dependency at install time rather than run time.

I have a working example of bitcore-lib running as a peerDependency at bitcore-docker-build which is also running testnet at bitcore.soapbubble.online/insight

I also updated bitcore-lib to 0.14 because bitcore-wallet-service has already done so and I figured if it was good enough for bitcoin-wallet-service it's good enough for everything else 😄

[CaptEmulation]

Also depends on:

• Use bitcore-lib as a peerDependency bitcore-node#500
• Use bitcore-lib as a peerDependency bitcore-p2p#92
• Use bitcore-lib as a peerDependency insight-api#501
• Use bitcore-lib as a peerDependency bitcore-wallet-service#639

[coveralls]

Coverage remained the same at 100.0% when pulling 2c09ad7 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a5431 on bitpay:master.

[CaptEmulation]

well from a Travis CI perspective I certainly see the flaw in my plan

[coveralls]

Coverage remained the same at 100.0% when pulling c090e45 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a5431 on bitpay:master.

[coveralls]

Coverage remained the same at 100.0% when pulling c367194 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a5431 on bitpay:master.

[coveralls]

Coverage remained the same at 100.0% when pulling b2347d0 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a5431 on bitpay:master.