SmartBot now gives smarter hints about playability.

I noticed that when Alice has a hand of all 1s, Bob will hint to her
that they're all 1s (all playable). Then Alice plays one of them,
which clears the isPlayable flag on the others (since all she knows
about them is that they're 1s). Then Bob hints to her that the remaining
three cards are 1s (and thus playable). Then Alice plays one; then Bob
hints about the remaining 1s; et cetera.

The proper tactic in this case would be for Bob's second hint to be
about the *color* of Alice's playable cards, rather than repeatedly
hinting about the value Alice already knows. This patch makes that happen,
although probably not in the best possible way.

This patch improves SmartBot's average score by 0.02 ppg and its
win percentage by 0.2%.
SmartBot is now faster! No functional change.

Finally refactor the whole isPlayable/isValuable/isWorthless
bookkeeping to happen "instantaneously": as soon as SmartBot
deduces that a card is fooable, it goes through and sets the
cantBe_ bits on all unfooable color/value pairs. This means
that the update() method itself no longer cares about the
incoming values of isPlayable and isValuable, which in turn
means that wipeOutPlayables() is obsolete.

This gives a 27.4% speedup when built with FAST=1 OPENMP=0,
and has no functional effect.
Refactoring SmartBot in preparation for trivalues.

Be consistent about the alphabetical ordering of "Playable",
"Valuable", and "Worthless".

Add a method bot.isPlayable(server,card) for symmetry with
isValuable() and isWorthless().

Rename couldBeValuable() to couldBeValuableWithValue(),
for clarity.

Refactor CardKnowledge::update() to enable trivalue logic
instead of boolean logic: in other words, we want to be able
to deduce when a card is definitely NOT p/v/w, just as
much as we want to know when it definitely IS p/v/w.
In this patch, we end up throwing away that information as
soon as we calculate it (i.e., we flatten our trivalue
NO/MAYBE/YES into a boolean NO_OR_MAYBE/YES); but this
enables us to incrementally refactor SmartBot to the point
where the information will not be thrown away.

No functional change. The new algorithm for update() is
significantly slower, but once we finish the refactor, it'll
be worth it.
"Fake" trivalues with a bivalued type { NO_OR_MAYBE, YES }.

No functional change.
Call knol.update() before knol.couldBePlayable().

The idea is that couldBePlayable() ought to be replaced with
playable() == MAYBE, and for that, we need setMustBe() to
interact with playable().

No functional change.
Trivalues for real!

The FAST=1 version of run_SmartBot is almost as fast again as it was
before my update() refactor.

No functional change.
Improve SmartBot's "discard oldest unknown card" heuristic.

Now that we have trivalue logic, we can improve our "discard oldest
not-known-valuable card" heuristic so that it will prefer to discard
cards that CANNOT be valuable.

This change boosts SmartBot's average score by 0.14 ppg, and boosts
its win percentage from 7.4% to 9.2% perfect.