Attester slashings are done in an arbitrary order and do not commute

[michaelsproul]

While testing Lighthouse against the new test vectors I encountered a discrepancy in the attester slashing tests which seems to arise from the spec iterating over the indices to slash in the arbitrary order used by Python's hashset implementation. The buggy line is:

for index in set(attesting_indices_1).intersection(attesting_indices_2):

in process_attester_slashing.

If slashings commuted the order could be arbitrary, but due to the exit_epoch being based upon the churn limit (and therefore the validators who have been previously slashed), you get different exit_epochs and different final states for different slashing orders. One test that exemplifies this is success_double (mainnet) which slashes [2, 143, 287, 353, 464, 475, 487, 496], which in Python set ordering is {353, 2, 487, 143, 464, 496, 475, 287}.

I think the best solution is to specify that the indices should be sorted before iteration, but I'm open to other ideas.