Sections 2.2 And 2.4.2 - we did not sanitize names for DbContext derived class which led to generating code that could not be compiled. The fix is to fix the name if it is invalid by removing invalid characters and prepending the name with '_' if it is a keyword, does not start with a letter or becomes empty string after removing invalid characters.
Merge branch 'Sanitized'
Sections 2.2 And 2.4.2 - we did not sanitize names for DbContext derived class which led to generating code that could not be compiled. The fix is to fix the name if it is invalid by removing invalid characters and prepending the name with '_' if it is a keyword, does not start with a letter or becomes empty string after removing invalid characters.
Updated bad input unit tests to cover more scenarios for codeplex 2078, 2081, 2082
rightType = right.ResultType.EdmType as RowType used to be rightType = left.ResultType.EdmType as RowType because of a typo (left. instead of right.) Previous change fixed the typo and uncovered
a worse bug. The two row types are compared with EdmEquals which enforces the facets of the members to match. In the repro case their MaxLength facets have different values, and thus the row types
are incorrectly considered incompatible, so the join predicate becomes false (1 = 0).
If we revert the typo fix the leftType.EdmEquals(rightType) will always return true and will be a no op. Instead we can remove the EdmEquals comparison. If the left and right expressions are coming
from LINQ their compatibility is ensured by the compiler. Otherwise (esql or manually built expression trees) we are less concerned with them being compatible because they can be fixed by the owner.
rightType = right.ResultType.EdmType as RowType used to be rightType = left.ResultType.EdmType as RowType because of a typo (left. instead of right.) Previous change fixed the typo and uncovered
a worse bug. The two row types are compared with EdmEquals which enforces the facets of the members to match. In the repro case their MaxLength facets have different values, and thus the row types
are incorrectly considered incompatible, so the join predicate becomes false (1 = 0).
If we revert the typo fix the leftType.EdmEquals(rightType) will always return true and will be a no op. Instead we can remove the EdmEquals comparison. If the left and right expressions are coming
from LINQ their compatibility is ensured by the compiler. Otherwise (esql or manually built expression trees) we are less concerned with them being compatible because they can be fixed by the owner.
adding more tests for issue 2093
One EF: Ignore foreign key column ordering when configuring the model

Issue:
Primary key column order is not specified in the provider model. Instead, we assume that it is the same as the table column order. Foreign key column order is, however. This can result in the primary key and foreign key column order getting out-of-sync.

Solution:
Ultimately, the database order doesn't matter to Entity Framework so long as things are consistent. To keep the orders in sync, table column order will also be used for foreign key columns.

Verification:
Manually verified -- creating and reverse engineering a database is not worth adding to the automated tests.

Work Item: 868
Merge branch 'release-6.1.0'

Conflicts:
	test/EFTools/UnitTests/EntityDesign/VisualStudio/CodeIdentifierUtilsTests.cs
	test/EntityFramework/FunctionalTests/FunctionalTests.csproj