Simplify sync committee aggregates

[ralexstokes]

The current Altair spec provides multiple partitions of the full sync committee with the idea being that light clients could follow some subset of their choosing to enable a trade-off between security and performance.

However, to efficiently implement this feature the BeaconBlock definition in Altair needs to support a distinct (aggregate) signature for each partition stored in the BeaconState. And currently we only have one such signature.

To reconcile this discrepancy, we can either add multiple signatures to the BeaconBlock (along w/ the corresponding increase in consensus complexity) or we can omit the in-protocol aggregation. This PR presents the latter solution and I'd argue it is a better trade-off at this point in time given the relative maturity of Altair client implementations.

[djrtwo]

looks good to me!

agreed that we could include a bit more in the docstring about usage and gotchas on the aggregate

[ralexstokes]

@hwwhww @djrtwo added some notes about duplicate pubkeys -- light clients should start with a bitfield and just blindly unaggregate based on participation so i'm not too worried about bugs here, but more documentation never hurts

[hwwhww]

LGTM!