`signTypedData_v4` encoding problems on extension

**Describe the bug**
Our `signTypedData_v4` implementation has various problems that make it easy to produce non-standard and/or non-portable encodings unintentionally. There are three main problems: our array encoding is not spec-compliant, we don't perform enough input validation, and we don't clearly document how each Solidity type should be encoded in the input data.

**Steps to reproduce (REQUIRED)**
See the `eth-sig-util` test suite for examples of nonsense inputs that we still accept or interpret in silly ways, and see [this issue](https://github.com/MetaMask/eth-sig-util/issues/106) for an explanation of the array encoding problem.

**Expected behavior**
We should ensure our `eth_signTypedData` implementation is spec-compliant, and that it does not produce non-standard/non-portable encodings, and that there is no remaining ambiguity in how data is interpreted. We can't accomplish these goals without breaking compatibility, so this will have to be released as `signTypedData_v5`.

See [the `eth-sig-util` `signTypedData_v5 milestone](https://github.com/MetaMask/eth-sig-util/milestone/2) for a list of related issues.

Start with the eth-sig-util test suite for the nonsense inputs referenced in the issue, then read eth-sig-util issue 106 for the array encoding problem. Review the signTypedData_v5 milestone for related work. Done means a spec-compliant, validated, unambiguous implementation released as signTypedData_v5 without non-portable encodings.

Written by the indexing model from the issue text.