Multiple sorting properties

Now you can do

var sortingOptions = new SortingOptions<Contact>("LastName");
sortingOptions.ThenSortBy("FirstName")

Fixes #81
Added methods to ISpecification so we could return that instead of a Specificaiton object

Also made static methods for creating a new specification from 2
specifications

var spec = Specification.Add(new Spec1(), new Spec2())

or

var spec = Specification.Add(x => x.IsActive, x => x.UserTypeId = 1)
Cleaned up XmlRepository

For some reason, previously we needed to clone the internal list before
using it for the queries, but that didn't seem right anymore.  So I
removed it and made sure all tests still pass.
DocumentStore and Session made protected instead of private

This will allow users to inherit from RavenDbRepository to get access to
the Session and make changes like using optimistic concurrency.  This
may not be the final solution but it fits with how the EF5 DbContext is
made available as well.
Changed specific private items to protected for MongoDb and Db4o repositories

Keeping consistent with Ef5 and RavenDb
Removed some hard-coded chace prefix

They all should be using the DefaultRepositoryConventions.CachePrefix
and now they are.
Introduced an automapping primary key feature

Automapping primary key feature on mongo db repository base using two
internal dictionaries as conversion tables
Merge remote-tracking branch 'upstream/master'

Conflicts:
	SharpRepository.MongoDbRepository/MongoDbRepositoryBase.cs
Changed specific private items to protected
Changed string to use BsonType.String instead of ObjectId
Fixes #85

Now the factory is respecting the Ioc loading of the DbContext if it is
completed successfully, and only falling back if there is no Ioc
container defined.

Added 2 tests to make sure you can load a Ef5Repository without defining
the connection string if you are using an Ioc dependency resolver, and a
second test to make sure that the DbContexts loaded are the same since
the Ioc container defines them to use the same one
Fix to allow for not defining dbContextType in config file if in the Ioc mapping

If your Ioc mapping (this is StructureMap example) defines a way to go
from a DbContext to a custom DbContext type, then you won't need to
define that in your config file since the Ioc will take care of it.
Added test coverage for this scenario and a small fix to allow it.
Included Data sub folder content in project

Trying to get the Data folders to be on the build server so the
integration tests pass now that I overwrite the content in that
directory after each build.  Hopefully this works.
Setting data readme files to copy always

Okay one more attempt to get these directories to be created on the
build server.  Sorry for cluttering up the master branch :)
Reverting last attempt :(
Performance gain on primary key lookup

Added a static dictionary that "caches" the PK lookup after the first
time.  This way it doesn't have to use reflection to get the PK property
of the entity after the first time.  It is 3 times as fast getting it
from the dictionary than using the Reflection based on my simple
testing.
Remove unused non-included files from source
Ioc cleanup

added NotImplementedException to the Ioc containers where the extension
methods aren't done

found bug in Windsor where it wasn't registering the IRepository<,>
correctly
Added ICompoundKeyRepository to windsor and ninject extensions
Added failing tests for multi-level magic string sorting

for example, "ContactType.Name"

Refactored LinqHelpers to remove duplicate code across the 4 sorting
methods.  Now just need to fix the failing tests next.