Test reorganisation for clarity

Better to test the ranking name distinct from the value
More faux-flesh on the PokerHand bones

Add hard-coded `rank` and `value` methods for test fudging.  Of course,
now they're not `attr_accessor` any more; remove that.
Keep an orderable version of the card's value handy

Since we're ranking and ranking is ordering, it makes sense to keep an
orderable version of the card's value easily accessible - you could make
this a method which calculated it each time but since it's static, we
might as well do it on construction to save effort later.
More flesh for PokerHand

Keep a numerically sorted list of the cards we have since it simplifies
life later.  Also keep a hash of the suits and values we have.
Starting to rank hands by Poker rules

(ab)Use our sorted list of cards and "count of suits" for Flushes.

Q. Since we have a static hand, would it not be better to put this
into the constructor rather than calculating it later?  Do we gain
anything by having this "on the fly"?  (A: If we have a river/flop,
probably, since then cards not in the hand can influence the rank,
maybe.  If I remember correctly.  Which I frequently don't with Poker.)
Final on-the-fly ranking code

This feels like terrible cheating and I'm sure there's a cleverer way
to do this - representing a hand as a collection of 5 6-bit values
(2 bits for hand, 4 bits for card) with the appropriate bitmasking and
comparisons might work.  Haven't really thought that through.  On the
other hand, this is a 2 hour project and getting something running is
vastly more important than making a lovely crystal space castle.

I hope.
Ranking code exposes a test case idiocy

Yep, I made a Straight for my High Card test.  Whoops.