Apply resource pattern to error describer service

- Follows Resource pattern (IdentityErrorDescriber.StringName, or FormatStringName(arg1, arg2)
- Also cleaned up optional services, by allowing null in constructor
- SignInStatus -> SignInFailure and introduced SignInResult to make SignInManager APIs consistent with IdentityResult (but no strings needed for SignIn)

Fixes: https://github.com/aspnet/Identity/issues/86, https://github.com/aspnet/Identity/issues/176, https://github.com/aspnet/Identity/issues/287 and https://github.com/aspnet/Identity/issues/177

cc @divega @suhasj 

I am ok with checking this in but I would like to chat with you about this (and also the similar change with null options that I see a few lines above) as a trend, i.e.:
1. Is this going to be null only if DI wasn't correctly setup or is there a use case in which it will be null. 
2. If there is no use case then should the system really fall back to something we consider reasonable if things were not setup or is it more useful to let the user know that DI isn't correctly setup?