BackToGroupTherapy - fix for workitem 1959
This is a new rule on GroupBy nodes that allows for a transformation on the tree that fixes the compatibility regression introduced by changeset a2444bf8acbf.
Converts a GroupBy(X, Y, Z) => OuterApply(X', GroupBy(Filter(X, key(X') == key(X)), Y, Z)) if and only if X is a ScanTableOp, and Z is the upper node of an aggregate function and the group by operation uses all the columns of X as the key.
Since now we're supporting NewRecordOp nodes as part of the GroupBy aggregate variable computations, we are also respecting the fact that group by (e => e) means that we're grouping by all columns of entity e. This was not a problem when the NewRecordOp node was not being processed since this caused the GroupBy statement to be simplified to a form with no keys and no output columns. The generated SQL is correct, but it is different from what it used to be and may be incompatible if the entity contains fields with datatypes that do not support being grouped by, such as blobs and images.
This rule simplifies the tree so that we remain compatible with the way we were generating queries that contain group by (e => e).
What this does is enabling the tree to take a shape that further optimization can convert into an expression that groups by the key of the table and calls the aggregate function as expected.
Never Mind the Collections, Here's the Nav Pistols (1977: Revert nav prop check back to IEnumerable)

From bug: In EF6 we switched a check that navigation properties are IEnumerable to one that checks if they are ICollection. This is because almost nothing works if the property is IEnumerable but not ICollection and the intention was to help people discover why their code would likely not work. However, as this thread indicates "almost nothing" is not the same as "nothing":  https://entityframework.codeplex.com/discussions/483925#post1150336
Adding interception for DbConnection.Dispose()
Adding tests for Connection and transaction interception.
YouPackageIsBeingProcessedByLocalFacility - 1st part of enabling adding EF NuGet Package for OneEF

This changeset adds vstemplates that will be used by OneEF to add EF NuGet Package to the project.
PackageDelivered - adding EF NuGet package to project for Empty Model CodeFirst

OneEF project items are now driven by CodeFirst vstemplate - it adds code project items as well as the the EF NuGet Package.
Changes:
- renamed EFNuGetPackage*.vstemplate to CodeFirst*.vstemplate since it now adds code project items to the project (it also allows localizing comments in code project items)
- removed logic for adding code project items from the ModelObjectItemWizard and ModelObjectItem*.vstemplate as it is now handled by the CodeFirst*.vstemplates
Issue 1811 - update EFTools nigtly build to allow for presence of dated runtime packages