Add download and path urls

[ruflin]

At the moment, only the /search endpoint contains the download url. This is now also added to the package info. In addition a field path is added which is the path to the package info. This should help with breaking changes in the future so EPM can rely on this information to find the info about a package instead of having to hard code it.

[jfsiii]

I like the flexibility/durability this adds. My only reservation is that path feel vague or generic, but I don't have a better name in mind at the moment, so let's take the incremental win now.

To expand a bit, path feels more like a type like string or URL than a descriptive name. e.g. We used download instead of download_path but both give the reader a sense of the purpose. Especially when you see "/package/example-1.0.0.tar.gz". But with path I ask "path to where?". What's at "/package/example-1.0.0"? I think that's the package info endpoint, but info seems as vague a key as path and I think I'd expect an object there; not a path/string.

Perhaps we could put the URLs under their own key like:

"paths": {
  "download": "/package/example-1.0.0.tar.gz",
  "info": "/package/example-1.0.0",
}

One nice thing about an object is we could nest the items that were more specific to how the registry works vs unique information about the package.

Again, I don't see an obvious replacement and am happy to keep things moving. Just want to put what I'm thinking in writing for us to consider.

[ruflin]

@jfsiii I share the exact same sentiment around naming and potentially having a better structure. Putting it in an object could be helpful, need to think more about this in the context of all fields.

For now will merge it and I kind of hope that if we add more fields it will become clear where things belong.