Fix proposalInfo mapping

[leviadam]

This PR is fixing #596.

The problem was that the mapping was from proposalId => proposalInfo. The reason that it cannot be part of the mapping which also contains the avatar, is that the result from the call from the voting machine does not contain the avatar.
This can be utilized by a malicious voting machine to overwrite another proposal. Note that it is not enough just to check that the proposalInfo is empty as it will be easy to predict the next IDs (the hash is deterministic) and freeze the DAO.

The solution is to have a mapping per voting machine, thus, if a DAO is working with a legit voting machine, its proposals are safe.

[orenyodfat]

How about adding additional require before setting avatar->proposalId->proposal ?
To make sure it cannot be overwrite by any voting which sneaked in (not likely to happened )

[leviadam]

I'm not sure about that @orenyodfat.
I think an organization must make sure the voting machine is producing random hashes. If this is not the case, then if you either throw or not does it not matter. If you throw, a DAO can be freezed. If you do not, a DAO's proposal can be over-written. I think freezing is worst.