Implement multi-candidate tickets

[stratofax]

Some candidate contests include multiple candidates (a "ticket") who receive a single vote.

For example, (from @trustthevote):

The [President / Vice President] contest is one of those where a single selection ID combines the names of two candidates. And there is a write in as well. So to be very precise:

• "two tickets of two candidates each"

actually should be:

• ballot selection items that combine the candidate for prez and the candidate for VP
• plus a write-in ballot selection item that is no different that for other contests.

Note that the EDF does specify pairs of candidates per ballot selection, so there is nothing magical about knowing which candidates form a pair, or which of the pair is for which office.

[ion-oset]

@trustthevote: some clarification requested on CandidateSelection that have more than one candidate:

1. What's the most reliable property to use to validate the arity/expected N of the candidates in a ticket? It originally seemed to me it should be CandidateSelection.OfficeIds, since Office.Name would presumably need to appear on the ballot when there's more than 1 office. But OfficeIds can be empty. Does that imply that it's not a reliable source for the office name? If it isn't what is?
   • The list of CandidateIds can work but then what happens when it's incorrect, or when the list of OfficeIds isn't the same N?
   • Contest.Name is required but it doesn't actually have to contain the office name.
2. It would presumably an uncommon or rare case if it wasn't so, but is there any actual requirement that candidates in the same selection / ticket have the same party?
3. We're assuming that the @id for a CandidateSelection is effectively the ID for the ticket (at least with plurality, majority or other VotesAllowed = 1 cases. I can't imagine how it couldn't be but we want to be sure there's no edge case, we're missing.

[ion-oset]

@cwulfman I'd be interested in your answers to these questions too.

[cwulfman]

I'm sounding like a broken record, but let's continue this discussion in the contest of the NIST 1500-100 spec.

There are several levels of indirection to bear in mind. In the case of offices, there are:

1. Office: For defining an office and information associated with a contest and/or a district. In a distributed system, this might be something defined by a municipality, or a county, or the state; it is independent of any particular election.
2. CandidateContest: For defining a contest and linking the contest to the associated candidates. It is specific to a particular election. Election-Level
3. OrderedContest: For the appearance of a contest on a particular ballot style. BallotStyle-Level

There is a similar hierarchy for people:

1. Person: For defining a person and associating biographic information with him/her (name, age, profession, etc.). In a distributed system, this would come from a separate database.
2. Candidate: For defining information about a candidate in a contest. Like CandidateContest, it is specific to a particular contest in a particular election. Election-Level
3. CandidateSelection: For the appearance of a candidate (or candidates!) in a particular OrderedContest on a particular ballot style. BallotStyle-Level