A few cosmetics
1. Function GetEdmSpaceType shouldn't belong to region "ApplyChanges Helpers"
2. Function GetEdmSpaceType must return null in case of multiple OSpace types found for entity type (more consistent with the old solution)
3. Move function GetEntitySetName to public. Add comment
Merge branch 'cosmetics' of https://github.com/azabluda/TrackableEntitiesContrib into azabluda-cosmetics
Corrected xml comment on GetEntitySetName.
Annoying <Service Include> in test project files
See http://stackoverflow.com/a/22917902 and https://connect.microsoft.com/VisualStudio/feedback/details/800245/vs2013rc-adds-to-vs2012-c-project-section-itemgroup
Fixes #5
LoadRelatedEntities: if the `items` collection contains entities of different type (due to inheritance) the it is not legitimate to inspect/load the properties declared only in the first element of the collection
May seem unrelated but it is actually a prerequisite for http://trackable.codeplex.com/workitem/38 "Properly Short Circuit Circular Recursion"
Eventually it should also facilitate http://trackable.codeplex.com/workitem/35 "Add Support for Inheritance"
Strange, we don't seem to need any protection mechanism against endless recursion in LoadRelatedEntities
Reflect Tony's recent changes in class OrderDetail (6c28a09c) in the EDMX file
FamilyModel: self-referencing `Child` class instead of separate `GrandChild` and `GrandGrandChild` classes
About 18 unit tests fail because of improper check for circular references based on matching types of master and detail entities
Class `Parent` isn't logically needed but hasn't been removed to keep the complexity of the model a bit higher than trivial :)
Remove unused parameter `ITrackingCollection changeTracker` from `TrackableExtensions.SetState`
New class `ObjectVisitationHelper` facilitates proper circular references checking when iterating the graph nodes
Just remove `_entityIdentity` and it still passes all tests
TODO: if this attempt incurs no other problems, then the T4 templates and sample apps must also be cleaned up
Proper circular reference checking in TrackableEntities.Common and TrackableEntities.Client

The new mechanism revealed a few older defects. Those have been fixed, but more thorough code review is advised!

Function `TrackableExtensions.SetState`
- handle Unchanged the same was as Added
- avoid recursion when setting Unchanged of Added states to M-M properties

Function `TrackableExtensions.GetChanges`
- non-recursive for M-M properties
Proper circular reference checking in TrackableEntities.EF5 and TrackableEntities.EF6

The new mechanism revealed one defect which has been fixed, but more thorough code review is advised!

Function `DbContextExtensions.ApplyChanges`
- state Unchanged wasn't set correctly for M-M detail entities
Avoid heavy abuse of arrays, stick to IEnumerable whenever possible
I guess Tony wasn't happy either about converting a lot of enumerables into arrays
Apparently the trap was here: `params object[]` arguments of `GetKeyValues` function
Proper circular reference checking in unit test helpers
- `TrackableEntities.EF.Tests.TrackingStateHelper.SetTrackingState`
- `TrackableEntities.EF.Tests.TrackingStateHelper.GetTrackingStates`
- `TrackableEntities.EF.Tests.TrackingStateHelper.GetModifiedProperties`
- `TrackableEntities.EF.Tests.DbContextHelper.GetEntityStates`
Fix `Accept_Changes_Should_Mark_Employee_With_Territories_Unchanged` unit test
Now as `GetTrackingStates` function properly inspects the entire graph and not just the 1st level details of employee, the Assert statement has become incorrect (always was?)
I suggest to check that the statuses of all objects of the graph are Unchanged after AcceptChanges, no matter how many objects were actually found
Simplify a bunch of recursive algorithms
Code cleanup
New method ObjectVisitationHelper.FindVisited
Fix a few bugs in IdMatcher
Extend `LoadRelatedEntities_Should_Populate_Order_With_Customer_With_Setting` unit test to demonstrate the (old) shortcoming in `LoadRelatedEntities` function, which would have troubles loading circularly referencing entities: either a complete "no go" or at least could lead to duplicated entities (same ID but different instances)