Build: Update $(ProgramFiles)\MSBuild to $(MSBuildExtensionsPath32)

Work Item: 2472
WhoIsAboutToMoveMyExportProvider: Taking a preemptive move to dodge an upcoming breaking change in VS 14 CTP4: they are replacing Visual Studio's MEF hosting with a VS-specific implementation. As part of this change they are disabling IComponentModel.DefaultCatalog and changing the recommended way to obtain a MEF ExportProvider to IComponentModel.DefaultExportProvider, and API that existed before. We were using IComponentModel.DefaultCatalog just to obtain the latter so I am simply changing our code to use IComponentModel.DefaultExportProvider in all versions.
Adding errors from memory-optimized tables to SqlAzureExecutionStrategy.

Workitem: 2458
Making WithCurrentCulture public and making it store the UI culture too.

Workitem: 2425
Penny the pig is mad. Hubert is mad too. Trent does not care.
Careful! Don't fall into the stream... (2468: DatabaseLogger throws System.ArgumentOutOfRangeException)

DatabaseLogger has a mode where it writes to a file using a StreamWriter. This can be used by multiple threads concurrently, but the StreamWriter is not thread safe. This change locks while doing the writes to prevent concurrency issues.
Foot in the door... (2447: Need a public method in DbModelBuilder)

This change creates a public non-generic method for registering entity types on DbModelBuilder. It does not allow further configuration of the entity type since this would require quite extensive changes to the fluent API surface which is heavily based on generics. However, these is still some value to this method because it is not uncommon to want to register types dynamically and then have the model configured by conventions--for example, this is what DbContext does by default. EF7 will allow full configuration without using generics.

I gave this method a different name than the current internal method since I know a fair amount of code already accesses that method using Reflection. The return type of the public method is void and both making the internal method public and changing its return type could cause Reflection code to break.
Bug 952621: DTS: EF creates unnecessary joins when using derived types.

When the PreProcessor encounters a navigation PropertyOp it rewrites the corresponding node into one that represents a query. The query is then added as nested subquery to the first RelOp ancestor. When the RelOp nodes are processed, the SubqueryTrackingVisitor creates a chain of outer applies: if S1, S2, ... are the subqueries and D the original (driver) input, the output created looks like OuterApply(OuterApply(D, S1), S2), ... Later in the plan compiler, when the transformations are run, the outer applies are transformed into left outer joins. If a Linq query projects multiple properties of an object accessed via a navigation property (x.NavProp.P1, x.NavProp.P2, ...) the final query ends having duplicated joins. The JoinElimination phase tries to eliminated duplicates but does not cover complex cases.

Instead of attempting to enhance the JoinElimination phase further, and make that code even more complex, the fix eliminates the duplicate subqueries early, in the PreProcessor, by caching and reusing the rewritten nodes. The logic for cache hits is implemented in the NavigationPropertyOpInfo class. Basically two navigation property nodes are considered equivalent from the cache point of view if they have the same RelOp ancestor (not null), same navigation property (EdmMember) and the subtrees having them as root are equivalent. For fast retrieval GetHashCode computes a hash code using the RelOp ancestor's hash code, the navigation property's hash code and the node's computed hash value.