dominoes: test singletons that can't be chained

[petertseng]

Some solutions may automatically declare a singleton input to be valid
without checking it can actually be chained. Singletons still need to be
checked because a singleton (1, 1) can be chained with itself, but
(1, 2) can't. This adds a test for (1, 2). The test for (1, 1) already
existed.

The example solution needs to be corrected to address this as well.

[petertseng]

@EduardoBautista if you would not mind reviewing at some point (I know, I know, it's pretty small change, but I ask in case I missed anything). It is not urgent because this problem doesn't get a lot of submissions and I can point out the problem to any submissions I came across in the meantime, so don't worry too much, just want to make sure it happen sometime

[petertseng]

Oh, or @IanWhitney too (and welcome!)

[IanWhitney]

Thanks!

Looking at the Swift tests, I see they also have this test. So adding it makes sense to me.

Should we extract these tests out to a common dominoes.json in x-common?

[petertseng]

I just added the test to Swift as well, so indeed!

Why didn't we make dominoes.json sooner? Because until Swift implemented the exercise, Rust was the only language with the exercise so it wasn't particularly high value. At this point in time it would make sense to do so (and it will make even more sense as more tracks implement the exercise).

If nobody has done it by the weekend, I would like to do so, but anyone can feel free to beat me on the punch.

One note to leave in the json document - it's likely that the JSON document will only be able to express "can a valid chain be made out of this domino list or not?" - it may be up to the individual tracks to check the actual chains for validity.

(The other possibility is to actively list out all possible chains but this gets highly complex with even just three dominoes (1, 2), (2, 3), (3, 1) since the possible chains are that order, any rotation of that order, and any rotation of that order with all dominoes reversed)