Create fake menu reader as a stand-in for a real reader

CCHFakeMenuItemsReader is used only in tests. Using a fake
object (or test double) to play the CCHMenuItemsReader role
instead of a real menu reader object has several benefits:

1. Test doubles are very easy to make. Nothing hinders
you from creating one for every possible situation. Each
variation is like an artist’s sketch. It emphasizes a single
interesting feature and allows the underlying object’s
other details to recede to the background.

2. We can return a canned answer (or value) from test
doubles. It might look like these test doubles are quite
limiting in terms of functionality, but that's the whole
point. The fact that they always return a pre-determined
value is perfect. This stubbed return value provides a
dependable foundation on which to construct the test.

3. Using test doubles to inject dependencies helps us
decouple the test from actual class. It no longer matters
if CCHMenuItemsPlistReader (the real menu reader object)
is slow because CCHFakeMenuItemsReader is always fast.

As a result, the test doubles are simple, fast, isolated
and intention revealing during testing.

For more information on this topic, please refer to the
“Testing Incoming Messages” section from Chapter 9
of Practical Object-Oriented Design in Ruby book:
http://goo.gl/NZ9Isu
Ensure CCHFakeMenuItemsReader conforms to CCHMenuItemsReader protocol

This test is important even if it's for a fake object that will only
be used in tests. Imagine that the code goes through some
changes: CCHMenuItemsReader's interface changes from
readMenuItems to readItems, but CCHFakeMenuItemsReader
continues to implement readMenuItems and not the new
method readItems. Furthermore, imagine that we failed to
update the name of the message (readMenuItems) sent to an
object that plays CCHMenuItemsReader role in application code.

The test continues to pass even though the application
is definitely broken. We have created an alternate universe,
one in which tests cheerfully report that all is well despite the
fact that the application is manifestly incorrect.

We could inject the real menu reader object instead of
the fake object and this problem could go away. However,
using fake objects have multiple benefits including fast
tests. There is a simple solution for this problem: The
application contains a CCHMenuItemsReader role. This role
originally had one player, CCHMenuItemsPlistReader. When
we created CCHFakeMenuItemsReader, we introduced a
second player of the role. When the interface of a role
changes, all players of the role must adopt the new interface.
It’s easy, however, to overlook role players that were
constructed specifically for tests and that is exactly what
happened here. CCHMenuItemsPlistReader got updated
with the new interface but CCHFakeMenuItemsReader
did not. If we had a simple test that made sure that
CCHFakeMenuItemsReader always conformed to
CCHMenuItemsReader protocol, then this alternate universe
would not have been created in the first place. That's exactly
what this commit does.

For more information on this topic, please refer to the
"Proving the Correctness of Ducks" section from Chapter 9
of the Practical Object-Oriented Design in Ruby book:
http://goo.gl/NZ9Isu