Consider flag for making VC `first_success` parallel

[michaelsproul]

At the moment the first_success function in the VC makes requests in order:

lighthouse/validator_client/beacon_node_fallback/src/lib.rs

Lines 613 to 618 in cfb1f73

	for future in futures {
	match future.await {
	Ok(val) => return Ok(val),
	Err(e) => errors.push(e),
	}
	}

This is sometimes sub-optimal in the case of block proposals, where we might want to get the first valid block proposal from any BN as quickly as possible, rather than trying the first one, having it time out, and then running out of time to ask any subsequent BN.

There is a design tension around how multiple BNs in the Lighthouse VC work. Originally we intended them to be "fallbacks", which would not be called upon unless there was an issue with the primary. We go to some effort to avoid burdening the fallbacks with unnecessary requests. However, flags like --broadcast have shifted the role of fallbacks, to be more like a cluster on which the VC can rely (a more Vouch-like design philosophy). For large operators, this mode of operation is usually preferable, as they don't care about burdening fallback BNs (the hardware is over-provisioned) and they are willing to trade increased load for better redundancy and fewer failures.

At the downside of adding yet-another flag to the VC, we could add something like --parallel-duties to force all uses of first_success to be parallel. This would cover block proposals, block duties, attestation duties, etc.

This may have strange interactions with our tiering system for BNs, which tries to reorder BNs in order of health. A naive implementation would essentially turn off the tiering system, which could have some downsides:

• The fastest BN to respond is not necessarily the one on the correct chain, or with the most up-to-date view of the network. Mitigation: run in parallel on nodes batched by their tier status?
• TODO