Create explicit index objects for every index

[ajcvickers]

Currently some indexes are inferred from keys by Migrations when using relational models. Per design meeting notes every index should be created explicitly in the model.

[bricelam]

We need to be careful to avoid creating duplicate indexes in the database. Most databases create an implicit index for PRIMARY KEY and UNIQUE constraints. If you then explicitly create an INDEX on the same columns, a new, duplicate index will be maintained by the database.

[bricelam]

Marking for re-triage; this should probably be pri0. Without this, Migrations won't create unique indexes for 0..1:0..1 relationships effectively making them 0..1:* in the database.

Here are the main things that would change in Metadata:

Before	After
Key.IsClustered	Key.Index.IsClustered
ForeignKey.IsUnique	ForeignKey.Index.IsUnique

Migrations would then promote the indices' configuration to the CREATE..PRIMARY KEY AND CREATE..UNIQUE clauses and skip creating indexes associated with keys.

For foreign keys, everything should "just work" in Migrations since there is typically no implicit index on FOREIGN KEY constraints.

[bricelam]

Yes, the tests will need to be updated.

[smitpatel]

blocked by #3648
GraphUpdate tests are failing.

[smitpatel]

Decision:
We’ll create indices by convention for each foreign key. The user owns this index and is free to update or delete it. The index will not be used when reasoning about foreign keys or relationships.
We won’t create indices for keys. Keys will continue to mirror some of the metadata that can also be defined on index (e.g. SqlServerIsClustered) in both the core metadata (as annotations) and the Fluent API. If an index is created over the same columns as a key, both a primary key/unique constraint and an index will be created in the database (i.e. we won’t collapse them in Migrations).
-Brice

Implemented in #3764