Disallow 'Location' values that redirect

[thomashoneyman]

It is possible for a package Location to be a redirect to another HTTP location. Right now we will simply accept the text string and follow the redirect when fetching the code. However, we should really restrict these locations beyond their text format and:

1. Ensure the location is reachable (it exists)
2. Ensure the location is not a redirect (it is not a 301, 302, etc.)

Maybe these could be rolled together into "must return a 200 status code." When we fix this we will also need to update the Legacy.Manifest code to follow the redirects to the end, and set that as the package location instead of whatever is written in the bowerfile or the GitHub URL we have available.

[f-f]

This is a problem only for the legacy importer, because it crawls all the packages and looks for new releases. It will not be a problem in "normal registry operation", because once the importer is not running anymore and instead new registry operations are triggered by users, then only one package at a time (in a chain of possible redirections - the above issue is a problem because GitHub puts redirects in place when transferring repos) will be updated in the registry, leaving the other copies dormant. That is, unless the user decides to update more of them.

I don't think we should disable redirects in normal registry usage - I'm of the opinion that we should put as few conditions as we can on locations, since we mostly just care that we can fetch code from a certain location. If a user wants to reupload the same source for a few packages with different names, that should be fine by us.
One of the assumptions of the pull model that we have (where the registry fetches things rather than the user uploading them) is that the location doesn't need to be up all the time. For what we care it could be up until we fetch the package, and then go offline forever after that.