Doing a 2 key CompoundKeyRepository with InMemory implementation

Thought about doing the key as a params object[] like Ef5 does but
decided to try a <T, TKey, TKey2> approach to see how it works and how
it feels.

It all currently compiles but haven't tested it yet.
CompoundKey struct needed GetHashCode and Equals for use in Dictionary
Ef5 compound key repository
Spike using add, get and findall for InMemoryCompoundKeyRepository
EF5 spike integration for compound key

I made a one off integration test for EF5 since it's not easy to
integrate this in to the other integration tests at this point because
the difference in the interfaces used.  Hopefully we can figure a way to
clean this up a bit.  But overall the POC is working I think.

Still need implementations for the real caching strategies, that comes
next.
Added timeout and standard caching strategies

Needed to make a StandardCompoundKeyCachingStrategy because there was
already a version with a 3rd generic for the Partition.

We may want to create a StandardCachingStrategyWithPartition instead so
it's obvious what it is and then we can have a
StandardCachingStrategy<T, TKey, TKey2>.  I'll probably do that later
but it will be a breaking change so need to think it thry fully first.
Created StandardCachingStrategyWithPartition

This was needed to allow there to be a StandardCachingStrategy for
compound keys.

NOTE: This is a breaking change for people using the
StandardCachingStrategy with partitions currently.
Worked the compound key stuff into the configuration and RepositoryFactory

Now you can load a compound key repository via the configuration file or
structuremap, etc.
Refactored interface

Moved all the common operations into IRepositoryBase leaving the Get and
Delete that accept the primary keys in the main interface of IRepository
and ICompoundKeyRepository.
Added a compound key repository that uses Get(params object[] keys)

So now there are the 2 primary key type where you can define the types
of the keys for better clarity in seeing what it is, then there is a
general one that you don't define the type of the keys up front but can
use as many as you like.

Plenty of code cleanup and refactoring is needed.  Right now there is a
ton of code duplication as I was trying to get it working first.  Will
definitely need to clean it up and combine common code into sub classes.
Then once that is done I may make another version that takes 3 key types
as well.  I may stop there as it will cover most of the use cases I
would think, and if not the general version will work.
Some refactoring to get rid of some code duplication

Still more needed
Added CompoundKey with 3 generic types

Now you can define ICompoundKeyRepository<T, TKey, TKey2> and
ICompoundKeyRepository<T, TKey, TKey2, TKey3> which are more specific
and declarative in showing what the keys are.

Or you can use ICompoundKeyRepository<T> when there are more than 3 keys
in your compound key and do something like repository.Get(1, 2, "jeff",
14) for a 4 key compound key.

There are currently only implementations for Ef5 and InMemory.

Again a lot of code cuplication will need to be consolidated by
refactoring.
Merge compound key branch
CompoundKey for the new CacheRepository