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.
Ioc Dependency Resolver

Now we can use a shared dbcontext across all EF5 repositories by having
IOC control it's lifetime
Merge compound key branch
CompoundKey for the new CacheRepository
Updates to nuget packaging

No more manual addition of config transform file, now the packing
handles it as it should.
Single config.transform file is now used to create an
app.config.transform and web.config.transform that NuGet will use based
on the type of project the package is being added to.
Remove left over test code
Preparing for 1.2 release
PoserShell script to clean duplicate entries w/ nuget

When NuGet does an update, if you have changed the config file entries
from what they are when initially installed (for example, changing the
connection string for a EF5 repository, or changing the timeout value
for the TimeoutCachingStrategy) then NuGet adds a new entry at the
bottom of the list.  The problem is that the name is the key and then
the project errors out because you can't have duplicate keys in a
section.  So the Install.ps1 script checks the web.config and/or the
app.config file to see if there are duplciate entries and if so removes
the last ones since they are the dups that were just entered.

Fixes #63
Random