Add TypedDataUtils.hashStruct tests

[Gudahtt]

This function should now be comprehensively tested. The tests mirror the TypedDataUtils.encodeData tests exactly. Any uses of
hashStruct in the older signature tests have been removed, as they are now redundant.

[Gudahtt]

This depends upon #169

[rekmarks]

These tests do mirror the encodeData tests exactly, and I'm wondering why we're going through all the trouble. Given that the only operation of hashStruct is to call ethUtil.keccak with the return value of encodeData. That being the case, what exactly are we testing, here?

Unless we are trying to test keccak itself, it seems to me that this entire PR could be reduced to a single test case:

describe('hashStruct', () => {
  it('hashes the result from encodeData', () => {
    // set up some mocks
    expect(encodeData).toHaveBeenCalledOnce();
    expect(ethUtil.keccak).toHaveBeenCalledOnce();
  })
})

The test should probably be instrumented such that we're convinced that keccak is indeed called with the return value of encodeData, but you get the idea.

I want to discuss the matter, not actually block on it.

[rekmarks]

I dismissed my previous review because I really meant it as a comment. I want to discuss the matter, but I won't ultimately block on it.

[Gudahtt]

If we were to test just that keccak and encodeData were called, we'd be testing the internals of the function, not the behaviour of the function. If we swapped our keccak implementation out for another one that behaved slightly differently, or if we added operations before or after that call, or if the structure of the encodeData output changed, we'd miss all of those problems. Tests written like that fundamentally aren't useful - they don't do their job, and they make it more difficult to refactor.

The thoroughness here might not be useful though. I did consider testing just a few representative samples. I went with the whole test suite because it seemed just as easy, and I don't know how unlikely it might be for a broken keccack implementation to behave oddly for some Buffer inputs but not others.

[rekmarks]

LGTM!