Add Microsoft.Extensions.Identity.Core + Stores

[HaoK]

First cut at splitting Identity into:

This is a big change so figured we should get the ball rolling with the PR, and can go over this in person next triage. The biggest breaking change out of this is moving to a different namespace (Microsoft.Extensions) which requires new usings.

Microsoft.Extensions.Identity.Core contains:

• All interfaces (except SecurityStampValidator)
• UserManager and RoleManager classes (minus the CancellationToken hookup to RequestAborted) [But no SignInManager]
• Most options classes (except new SecurityStampValidatorOptions, and DataProtection/Token/PasswordHasher options)

Microsoft.AspNetCore.Identity contains:

• AddIdentity()
• All the implementations of the interfaces like PasswordHasher, PasswordValidator, etc
• Stub AspNet[User|Role]Manager implementation which only hooks up the CancellationToken
• SignInManager and SecurityStamp which are tightly bound to http/Authentication right now

Microsoft.Extensions.Identity.Stores contains:

• Basic pocos: IdentityUser etc (no navigation properties)
• User/RoleStoreBase abstract base classes which implement most of the grunt get/set store implementations using the poco, yet leave the most important CRUD operations as abstract.

Microsoft.AspNetCore.Identity.EntityFrameworkStores will contain[as of next iteration]:

• POCOs are eliminated.
• Stores derive from new base stores.

Next steps: need to look into refactoring some of the sign in functionality like lockout back into UserManager.

@divega @ajcvickers @blowdart

Fixes: #651 and #883

[HaoK]

@ajcvickers updated PR with what we discussed (keeping the old AspNetCore namespaces).

There is still one minor breaking change with the POCOs moving from Microsoft.AspNetCore.Identity.EntityFrameworkCore => Microsoft.AspNetCore.Identity, this isn't as big of a deal since most references are already including both, but there will be a few places in the models that will need to change the using.

[HaoK]

e6f3ebf

[kevinchalet]

@HaoK is there a particular reason why the EF Core stores have to depend on Microsoft.AspNetCore.Identity instead of just Microsoft.Extensions.Identity.Core? (IdentityBuilder could be moved to Core).

[HaoK]

@PinpointTownes no particular reason, that's a good idea, I can move the builder to Core and switch the stores to depend on only on the extensions, so effectively we can rename it to Microsoft.Extensions.Identity.EntityFrameworkCore, something we can consider post preview2

[HaoK]

I'll file an issue so we don't forget