[Sharding] Calc the right root with respect to (slot, shard) for an empty PendingShardHeader

[Nashatyrev]

While processing attestation we are searching for the PendingShardHeader in the state via it's root.
So we should either

• put the correct root (involving slot, shard) for an 'empty' header when populating current_epoch_pending_shard_headers
• or stick with another search heuristics

This PR resolves the issue via the first variant

[protolambda]

If an attestation votes for all zeroes in the shard-root, that should just work. I agree that all current signature infra is built around containers and signing roots, so signing an empty header is probably practical.

The attestation data already includes sufficient information to avoid replay attacks (i.e. it includes the slot and beacon root info, so a signature of the attestation with empty shard data is still unique), although it doesn't hurt to put it in the shard thing too.

I am not sure about the proposer index and body contents though:

• The validator client may be confused when signing an attestation for a shard blob header with mismatching proposer index to attest to the "empty" case. The 0 index is just valid. Later on, the validator client is supposed to check custody over the shard data, it's not just an opaque root from the beacon node that it is signing.
• The body root can never be fully zeroed in the expanded case.

I think I lean towards leaving this as-is. Attestations for empty shard data vote for a zeroed shard blob root should just work. And the actual vote target is clear from the attestation data slot, index and beacon_block_root fields. The one field may be the same, but the attestation is still unique.

[Nashatyrev]

Yep, leaving an empty root for an empty data sounds like a better solution actually (at least from the tracing/debugging point of view).
Reverted my previous updates and fix the update_pending_votes search criteria: 3cc1256

[protolambda]

LGTM, and sorry for review delay.