Navigating to the right foreign land... (Add error checking/robustness to FK/navigations in core metadata)

This came out of issues where Keys would be left dangling when attempting to build and change relationships with the fluent API. It also means that obviously wrong metadata such as navigations that don't match CLR properties are flagged early.

Sometimes we need to address properties and navigations as unified things, and sometimes as independent things. I will file an issue for us to discuss whether this means that they should be unified within the EntityType data structures. Also, navigations are currently not stored in deterministic order, which may not be a problem since they aren't used in the store model, but is something that should be considered.
Let me newgle that for you... (Support uninitialized collection navigation properties)

Issues #451, #152

Specifically:
- Collection can be null for Contains and Remove calls
- Collection is initialized if possible if null when Add is called. Same rules used for the type to instantiate as in EF6.
- Error checking for when we can't use/initialize the collection
Hiring a temp... (Allow property values to be marked a temporary)

This is a small change to allow property values in Added entities to be marked as temporary. The code reuses generalized IsModified storage since that flag is only used in Modified entities while this flag is only used in Added entities. See https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes---July-10,-2014#value-generation
Improvements to entity tracking of query results.

- Entities not returned by the outer result set are no longer tracked.
- Introduced a query StateEntry buffer to isolate query execution from the StateManager.
Remove PathResolver
Target aspnet50
Update .csproj files
Skipping tests to unblock CI