Potential changes to SCP ballot validity checks

[bboston7]

CAP-83 adds a new StellarValue type that will enable us to modify stellar-core to optimistically begin SCP while downloading transaction sets in parallel. If we allow this parallelism to continue through early phases of balloting, we will need to change some SCP behavior to properly handle cases where the downloaded transaction set is invalid. We're currently weighing the following options:

1. Fully relax validity checks. We could remove all transaction set validity checks on outgoing and incoming ballots. This means that it would be possible for SCP to confirm commit an invalid transaction set. If an invalid value were confirmed committed, SCP would obscure this fact to the application layer by converting the value to a Skip value when passing it off. However, observers of SCP would notice the distinction between what was confirmed committed and what the application layer saw.
2. Require transaction sets before balloting. We could avoid relaxing any validity checks by only permitting parallel transaction set downloading during nomination. Implementation wise, this is not necessarily simpler than permitting transaction set downloading into early phases of balloting.
3. Partially relax validity checks. This option is similar to option 1, but only relaxes the validity checks on p and p' within PREPARE messages. SCP would not confirm commit invalid transaction sets, but SCP participants would now need to permit invalid p and p' values.

We're leaning towards option 3 here, but are still evaluating the implementation complexity of that change. If options 1 or 3 are selected, we will either open a new CAP for the relaxed validity checks, or fold the SCP change into CAP-83.