Fix #253 by providing support for Microsoft Account Login

Here it is! The BIG ONE! OAUTH! :sparkles: YAY! :sparkles: 

Fixes #253 

Table of Contents:
1. [Deployment Notes](#dep)
2. [Testing Notes](#test)
3. [Code Review Notes](#cr)

Terms:
MSA = Microsoft Account
NGA = NuGet.org Account

# <a name="dep"></a> Deployment Notes
1. Work with Jeff and Andrew to provision accounts for the various NuGet Environments at https://account.live.com/developers/applications
2. Update CSCFG with values for Auth.MicrosoftAccount.[Enabled/ClientID/ClientSecret] based on the data from Step 1

# <a name="test"></a> Testing Notes
Testing this feature requires a few extra hoops. First, be preared to use Private Browsing modes often. Once you have associated an MSA with an NGA, in order to sign in using a different MSA you have to either 1) Wipe our your cookies 2) Log out of ALL Microsoft Account sites or 3) Use Private Browsing mode (I recommend 3 :)). Also, always open a brand new Private Browsing mode window when starting to test with a new MSA, as it appears that tabs within a Private Browsing window sometimes share cookies (?).

In general, the following high-level elements should be tested:

1. Nothing has changed about API Key and Password auth, all existing scenarios there should work

2. Logging in with a never-before-seen MSA which has an email address that has never been registered with an NGA. ==> This should yield a register/signin flow

3. Logging in with a never-before-seen MSA which has an email address that IS registered with a current NGA. ==> This should yield a signin flow for that email address

4. Logging in with previously-seen MSAs should immediately log you in to the associated account

5. Entering invalid data at any point should produce the expected validation errors without interrupting the flow.

6. From the Manage Credentials dialog it should be possible to do the following:
 1. Add a password to an account which was created via MSA login
 2. Remove a password from an account that also has an MSA associated
 3. Remove an MSA from an account that has a password associated
 4. Remove an MSA from an account that has a second MSA associated (see next item)
 5. **It should never be possible to remove all MSAs/Passwords from an account, there must always be at least one MSA or Password associated**

7. It should be possible to associate multiple MSAs using a flow like the following:
 1. Log in to NuGet using MSA **1**, associate with NGA *alpha*
 2. Ensure NGA *alpha* has a password associated with it
 3. (New Private Browsing window) Log in to NuGet using MSA **2**, associate with NGA *alpha* using its password
 4. You should now be able to use either MSA **1** or MSA **2** to log in to NGA *alpha*
 5. You should see MSAs **1** and **2** on the Manage Credentials page.

**Please take extra care to ensure you are using the correct MSA before authenticating. Maybe even just assign each MSA you want to use for testing to a different browser engine (Chrome, IE, Firefox, Safari, Opera, etc.) :)**

## Bug Bar
This is just my (anurse) opinion, but the bug bar should be something like the following:

1. If a bug aborts the MSA linking flow but does not corrupt data and the user is able to retry the flow, having corrected the error -> Bug
2. If a bug corrupts the MSA linking flow and makes it impossible for the user to recover -> Ship Blocker
3. If a bug allows MSAs to be associated to incorrect users -> Ship Blocker

# <a name="cr"></a> Code Review Notes
This PR introduces a few small changes and one major new feature.

## Auditing
Auditing is handled in the NuGetGallery.Core assembly, in the NuGetGallery.Auditing namespace. A subclass of AuditingService, most commonly a CloudAuditingService, is constructed and provided to various other components in the system. This service receives objects deriving from AuditRecord. An AuditActor is synthesized using information from the ambient environment and the two are combined into an AuditEntry. The AuditEntry is JSON serialized and uploaded to a blob in blob storage (the name of which is derived from the object being audited, the current UTC time, and the action being performed).

An AuditActor represents an actor in the system. It has a machine name, IP address, user name and authentication type. An actor can also be performing the operation on behalf of another user, and that other user is encoded within the AuditActor itself. So for example, in a web application, an AuditActor is created for the Web Server itself containing the Machine Name, IP Address and Local Windows User Name of the Web Server Process. However, the server is acting on behalf of a client, so a second actor is created containing information about this client and that is embedded within the server using the AuditActor.OnBehalfOf field. The entire graph is serialized to JSON when the AuditEntry is stored.

**IMPORTANT: Audit Data includes the Client IP address. Ensure your terms of service are clear about this (NuGet.org's are).**

## Font Awesomer
We are now using Font Awesome in more places rather than reinventing our own icons. :sparkles: so code reuse :sparkles:

## Authentication
The Gallery authentication model has been massively overhauled. The fundamental method of identification in the system remains a Local Session Cookie, created and managed by the Microsoft.Owin.Security.Cookies middleware provided by the [Katana Project](http://katanaproject.codeplex.com). One secondary method of identification is allowed, the X-NuGet-ApiKey header, but ONLY on Actions bearing the ApiAuthorize attribute (i.e. those in ApiController).

Now, however, instead of relying on a single hard-coded mechanism of checking a user-name/password pair to locate a user record and create a Session Cookie, we allow custom "Authenticators" to participate in the process. An authenticator is just a public concrete class inheriting from Authenticator<T>. Aside from the authenticators provided to support Local Session Cookie and Api Key authentication, a new authenticator is provided for Microsoft Account authentication (see below).

## Microsoft Account Authentication
Microsoft Account Authentication is provided using a custom authenticator which, when asked to get authentication information from the user, redirects to the Microsoft Account OAuth endpoints. On returning from MSA (Microsoft Account), it writes a ".AspNet.External" cookie containing the data it found. This is NOT a proper session cookie, but it does signal to the rest of the site that the user is "half-authenticated"

The partial authentication cookie created during MSA auth is used to look up a user record. The MSA User ID is checked against the Credentials table. If a match is found, the user is authenticated and the process is complete. If no match is found, the Email address is checked against the Users table. If a match is found, the user is prompted to enter the password for that account in order to link this credential with that account, once that is done, the account is linked and the user is logged in (future authentications will go through the first path now). If no matches are found, the user is prompted to either create a new NuGet.org account or enter the user name/password for an existing account to associate that account.

## Credential Management
The Change Password page has been replaced by a more significant "Manage Credentials" page which allows users to:

1. Remove any credential, except for API keys and the LAST remaining login credential (Password/MSA)
2. Reset the API Key
3. Change their password
4. Set a password, if one was never created for the account, by using the Forgot Password flow of sending an email to the user with a confirmation token.