Support Role Permissions

-	Identity.Entity now means only Sql Server EF Identity implementation
-	Identity.Entity.InMemory moved to a test project (Identity.Entity.InMemory.Test)
-	Identity.InMemory which was the identity in memory implementation also moved to a test project (Identity.InMemory.Test)
-	IClaimsFactory was promoted to a top level service and now adds any claims found in a Role that a user belongs to.
-	EF implementation now supports logins, claims, roles, two factor, lockouts
-	Initial pass at style cop (mostly line endings since resharper no worky :()
We decided some time ago we would try defining our extension methods on the namespace of the target type, as opposed to the normal framework namespace of the sponsor class. That way where this is used, e.g. in the start up class you only need to bring the DI namespace and that will put all the extension methods that apply to DI in scope, from all the dependencies declared from the application.

From: Hao [mailto:notifications@github.com]
Sent: Friday, June 20, 2014 12:06 PM
To: aspnet/Identity
Cc: Diego Vega
Subject: Re: [Identity] Support Role Permissions (#124)


In src/Microsoft.AspNet.Identity.Entity/EntityIdentityBuilderExtensions.cs:

> @@ -5,27 +5,16 @@

>  using Microsoft.Data.Entity;

>  using Microsoft.Framework.DependencyInjection;

>

> -// Move to DI namespace?

I guess I don't understand that pattern, why would the IdentityBuilder extensions which live in Microsoft.AspNet.Identity show up when you import DI instead of automatically when you import Identity? That makes sense for ServiceCollection which lives in DI, but not as much for the identity specific builder

—
Reply to this email directly or view it on GitHub<https://github.com/aspnet/Identity/pull/124/files#r14036238>.