Use try-catch statement around K-specific code in Design assembly
Initial impl of AsNoTracking
Updated build.cmd
EDMLib v4? (Metadata robustness and non-primary keys)

(This change looks big, but the only really substantive changes are in EntityType.cs)

This change adds non-primary keys as a first-class part of the model as per issue #537. In looking at this it became clear that it was time to add some more robustness to the core metadata to help prevent the model getting into inconsistent state--for example, removing keys that are being referenced by foreign keys. Most of this change is about adding that robustness. Specifically:
- Be explicit and consistent about being able to either find and existing metadata item or create a new one if it doesn't yet exist. This matches the way we tend to use metadata, especially from fluent APIs and conventions. It helps protect against a couple of bugs we have had recently where duplicate items (properties or keys) were added by mistake. The methods are currently called GetOrAddXxx, but we can discuss other ideas.
- Error checking for things like CLR properties actually existing
- Checks to prevent removal of items that are currently still being referenced in the model
Fix build break caused by Azure Table Storage model being built differently and inconsistently. Will file a bug to follow up on some of this.
Fix PackageReference items in Microsoft.AspNet.Diagnostics.Entity.csproj
Handle IBuilder rename to IApplicationBuilder.
Renamed DbMigrator back to Migrator.
Added ProductVersion column to the migration history table. The product version is obtained from the informational version atribute on the assembly. I added the conditional compilation symbol VSBUILD to the Migrations project to have an informational version when running tests from VS.
Added code for setting max length annotations on the columns of migration history table, using same values as EF6.
Updated unit tests and added test for insterting history row with custom context key.
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