Extend _txInputFormatter with hex prefix check

[nivida]

Description

_txInputFormatter extended with hex prefix check. I've kept the isHex utility function as it is because it is a part of the public API and would probably introduce a breaking change for some.

Edit:
I've changed the implementation to prepend the 0x prefix if not existing instead of throwing an Error. This will improve the consistency of the sent data property for eth_call and eth_sendTransaction as well just without breaking something. @cgewecke

Fixes #1082

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run dtslint with success and extended the tests and types if necessary.
• I ran npm run test:unit with success and extended the tests if necessary.
• I ran npm run build-all and tested the resulting file/'s from dist folder in a browser.
• I have updated the CHANGELOG.md file in the root folder.
• I have tested my code on the live network.

[coveralls]

Coverage decreased (-0.02%) to 89.814% when pulling 5f3e525 on issue/1082 into 9e46628 on 1.x.

[nivida]

@cgewecke As our test does bring up would this be a breaking change for Ganache. The more strict validation which does require any hex string to be prefixed with the known hex prefix '0x' does throw an error in many cases. This means we are probably forced to wait with a more strict validation of hex strings until 2.0. WDYT?

[cgewecke]

@nivida Yes, agree it looks that way to me as well. It's too bad.

Ganache has 7 failing tests. The original comment at the reporting issue says:

Both Geth and TestingRPC implementations are flexible enough to accept that payload as is, even though it doesn't strictly conform to the standard, but when I tested this code against a Parity backend I got a very unhelpful invalid params exception.

which means some people are probably passing the raw solc bytecode output directly to Geth too.

[cgewecke]

@nivida It looks like were forced to put the Hold label on this for the time being.

[nivida]

@ryanio This could get merged because it is backward compatible. web3.js will send anything with a 0x prefix but doesn't have a strict validation of the inputs.

[ryanio]

@nivida ah just coming across your comment, sorry I missed it when you first posted it. ok thanks we will include this in the next release.

[ryanio]

LGTM!