Allow light client to verify signatures at period boundary

[hujw77]

As the sync committee signs the previous block, the situation arises at
every sync committee period boundary, that the new sync committee signs
a block in the previous sync committee period. The light client cannot
reliably detect this condition (e.g., assume that this is the case when
it is currently on the last slot of a sync committee period), because
the last couple slots of a sync committee period may not have a block.

For example, when receiving a FinalizedHeaderUpdate that is constructed
as in the following illustration, it is unknown whether sync_aggregate
was signed by the current or next sync committee at attested_header.

                       
        slot N           N + 1   |            N + 2   (slot not sent!)
                                 |
  +-----------------+     \ /    |     +----------------+
  | attested_header | <--- X ----|---- | sync_aggregate |
  +-----------------+     / \    |     +----------------+
                        missed   |
                                 |
                          sync committee
                          period boundary

This patch addresses this edge case by including the slot at which the
sync_aggregate was created into the FinalizedHeaderUpdate object.

Note that the signature_slot cannot be trusted beyond the purpose of
signature verification, as it could be manipulated to any other slot
within the same sync committee period and fork version, without making
the sync_aggregate invalid.

Related ethereum/consensus-specs#2805