light client: split voting_power_in in two and eliminate dependency on validator_address field

[ebuchman]

The voting_power_in function takes a signed_header and validator_set and checks how much voting power the signers in the signed_header have in the given validator_set. Currently it's used for both check_enough_trust and check_signers_overlap, and it depends on reading the validator_address field in the commit_sigs of the signed_header.
However, we'll want to eliminate dependence on the validator_address field since it will eventually be removed tendermint/tendermint#5023.

The difference between check_signers_overlap and check_enough_trust is that in the former, the validator_set is the one that signed the signed_header, while as in the latter, it's not. By depending on the validator_address, the two uses can be collapsed to a single voting_power_in function since we know which address each signature is from and we can look up their voting power. But without the validator_address, we need to treat them differently.

For check_signers_overlap, the validator_set is the one that signed the signed_header, so we can just loop through the commit_sigs in order, as they will be in the same order as the validator set, so the ith commit sig should have been signed by the ith validator. This will eliminate the need to check:

• if a signer is in the set since we assume there's a (possibly empty) commit sig for each validator
• if a validator signed twice since the validator set should have already been checked for duplicates (though we might need to actually do that somewhere?)

For check_enough_trust, we now need two validator sets, trusted_vs and untrusted_vs. The former is what the validator_set was previously, the latter we need to get the validator addresses from to look up in the trusted_vs. So we would loop through the commit_sigs in order, get their corresponding validator address from the untrusted_vs, and then lookup that validator in the trusted_vs to get the voting power.

We should make sure this change is reflected in the spec first. This isn't urgent, but something to address in the coming months.

That said, so long as the validator_address is in the CommitSig, we should check it's correct for the given validator index ...