Review how we create/handle indexes in Reverse Engineer

[rowanmiller]

We've had a few issues around indexes, so rather than making isolated decisions without the all-up context we are creating an issue to take a holistic look at what we do.

Can you put together a summary of how we handle indexes and what needs to change. This should include the things discussed in:

• RevEng: Sqlite: Indexes for PK are scaffolded wrongly #3642
• Handle redundant PK indexes in RelationalScaffoldingModelFactory #3664

[lajones]

Per discussion on 11/24/15 with @rowanmiller and @ajcvickers we need the following:

1. FKs: If the name of the index matches that which the convention would automatically create then no need to add a separate index fluent API at all. But if the name is different will need to add it and then the runtime will use that index (matching based on FK properties in the correct order).
2. PKs: may need to define the PK and add ConstraintName() if the name of the underlying index is different from what the convention would assume.
3. Alternate Keys: we already generate these. Check that we correctly issue fluent API defining the name.

Issue #3642 was addressed by commit 9b8ea39 and PR #3764.
Issue #3664 will be revisited during the work above.

[lajones]

Note to self: point 3 above is already done (see https://github.com/aspnet/EntityFramework/blob/dev/src/EntityFramework.Relational.Design/RelationalScaffoldingModelFactory.cs#L303).

[lajones]

Note: for point 2 above the correct API is HasName().

[lajones]

Fix checked in with commit dbb5c9f.