Fix #811 by Normalizing Package Versions

Fixes #811 

This change normalizes package versions in URLs, when displaying, and when checking against duplicate packages. It also includes some ops tasks that will need to be run IMMEDIATELY before/after deployment to fix some package which will be broken after deployment.

# Test Notes
* Try uploading a package with some of the following version numbers and make sure the indicated normalized version is actually shown in the UI (Version => Normalized Version, and feel free to change the non-zero numbers to some other number if it helps, it's the pattern of the version and the zeros that matter):
 * 1 => 1.0.0 (might have to hack the nuspec to make this work, NPE and nuget.exe won't allow it)
 * 2.0 => 2.0.0
 * 3.0.0.0 => 3.0.0
 * 4.0.0.0-alpha => 4.0.0-alpha
 * 05.0 => 5.0.0
 * 6.2.01.1 => 6.2.1.1
* Similarly, after uploading these, try adding leading zeros or other denormalizations and re-uploading. You should get an error about the package already existing. For example, if the above versions all exist for a single package ID, try the following. All of these should FAIL due to duplicate versions existing:
 * 001.0
 * 1.0.0.0
 * 1.0
 * 5.0.0
 * 4.0-alpha
* Once uploaded, try installing some of these packages. You should ALWAYS get nuget installing the package into a folder name based on the version that's ACTUALLY IN THE NUSPEC. So if you upload a package with a version number of "6.2.01.1" and ID of "Foo", the site will display "Foo 6.2.1.1" **BUT** nuget should install it to "Foo.6.2.01.1".
* Try using various denormalizations of package versions in URLs. You should always be redirected to the normalized version using an HTTP 302 Permanent Redirect. For example: http://[siteroot]/packages/jQuery/01.09.01.00 should redirect to http://[siteroot]/packages/jQuery/1.9.1
 * Same for the /api/v2/package/jQuery/01.09.01.00 endpoint, except that it won't 302, it'll just return the appropriate package file (jQuery.1.9.1.nupkg)

# Custom Deployment Steps for this change:
**BEFORE**
- [ ] Migrate the database to the latest (this should be safe to do against the old code)
- [ ] Run the "galops ddpv" task (which is defined in this PR, so make sure you are either merged to master or switch to whatever branch has this task). Do this cautiously (use "-!" first to verify no unexpected errors, then rerun without) against Staging first and ensure that it creates an "auditing" container in the **nugetstaging** storage account with records for deleted packages. Once verified, run it against production. If available, have @anurse nearby when running it just in case :). The job creates backups and audit records so it should be fairly safe
- [ ] Run the "galops npv" (normalize package versions) task. Again, do this cautiously (with "-!" first), but this is much safer as all it does is add new data that the old code ignores.
- [ ] Run the "galops npf" (normalize package files) task. As before, do it cautiously first :). This is a non-destructive COPY operation though so it's fairly safe, but it MUST be done before deployment and AFTER "ddpv" is run because otherwise it may end up encountering two package blobs with the same normalized name, with undefined results.

**AFTER**
- [ ] What-If Run "galops ddpv" to check if any new duplicate packages were uploaded during the gap between the last run and deployment of the code that fixes the issue
- [ ] Run "galops npv" to fill in any missing data for packages uploaded during the gap.