consider deprecating seth --to-bytes32

`seth --to-bytes32` pads on the right when given an integer. This can be a very surprising behaviour, since the analogous-sounding `bytes32()` applied to a `uintN` in solidity will pad on the left (since it is a no-op at the word level). So a user can easily make a very costly mistake, for example in the following situation:

```
seth send $TUB_ADDRESS "lock(bytes32,uint256)" $(seth --to-bytes32 1337) $(seth --to-uint256 123456)
```

where it seemed reasonable to use `--to-bytes32` and `--to-uint256` to match the function ABI, but the consequences are disastrous, locking PETH into a CDP with a lot of hex zeros in its id 😲

The options I can see are:

(a) make `--to-bytes32` throw when given an integer, rather than a string or hex string where the right-padding behaviour is maybe slightly less surprising.
(b) add a way to specify padding side, crash unless padding is explicitly specified
(c) ???

cc @rainbreak