fix: use size of Base64-encoded ID to calculate ballot length for decryption

[PascalinDe]

To calculate the ballot length to construct the El Gamal pairs for decryption, currently the decoded ID is used. However, since the ID arrives encoded from the frontend, the length of the Base64-encoded needs to be used instead.

Also fixes the related tests that assumed that the ID was stored in Base64-encoded form when it is not (see e.g.

d-voting/contracts/evoting/types/ballots.go

Line 76 in 0ce24ab

q := form.Configuration.GetQuestion(ID(questionID))

where the corresponding question is retrieved using ID that has been decoded in ln. 71).

Also cleaned up the comments and cleaned up the code around the calculation of the ballot's size to make it more clear.

This resolves #167 .

Some more details:

• the error as described in Wrong calculation of ballot-size truncates choices of voters #167 was observed for 6 options, or a ballot size of 29
• the changes in this PR "shifted" the critical ballot size of 29 to 4 options
• manual tests with number of options 2, 3, 4 (ballot sizes of 25, 27, 29 respectively up to overflow), 5 (overflow into next pair) and 6 (led to error in Wrong calculation of ballot-size truncates choices of voters #167) were successful
• manual tests with 18 (ballot size of 57) and 19 (overflow into next pair w/ ballot size of 59) were successful too