Force topics to 32-bytes more cheaply and transparently

[jeff-aion]

Issue #326 changed our handling of logging topics to be hashed with sha256 in order to force the topics to be 32 bytes long. This is relevant since the rest of the system expects these quantities to be 32 bytes and Solidity quantities are naturally this size so we wanted to coerce the arbitrarily-sized AVM log topics into this shape.

sha256 was chosen, seemingly just because it was available and had the size properties we wanted. This, however, is a very slow way to truncate/pad a sequence of bytes (since that is ultimately all we want), which also has the consequence of requiring the user to sha256 any topic they wish to query. Further, this adds extra complexity to work being done under #354 where we would like to remove hashing/crypto functionality from the core of the AVM and this creates yet another place where this is required.

Instead, I propose that we define a simple topic sizing specification:

• null is invalid and results in NullPointerException
• any byte[] longer then 32 bytes is truncated to 32 by removing bytes at the end (higher indices removed while indices 0 to 31 remain untouched)
• any byte[] shorter than 32 bytes is zero-extended by adding bytes at the end (for byte[] of length n given, adding 0 bytes from index n to 31 while leaving indices 0 to n-1 untouched)

[jeff-aion]

Note that our internal helper will handle the null as NullPointerException but the AVM specification requires that API argument problems be handled as a IllegalArgumentException without any message so that is what will be visible to the user code.

[jeff-aion]

These changes currently apply only to the topics. No size constraints are currently applied to the data component of the log and this will be investigated under issue #359.

[jeff-aion]

Typo in the closing commit: b5c951d0dea65aab69733057e21e760dd256e84a