Relax package path assumptions in remotes:::download_version_url

[martinstuder]

remotes:::download_version_url assumes that packages in src/contrib/Archive are organized in a flat manner (like on CRAN). Artifactory, however, seems to organize archived packages by having intermediate version folders like src/contrib/Archive/<package_name>/<version>/<package_name>_<version>.tar.gz.

It seems like the package path assumptions could be relaxed to support both models.

[brianrepko]

Leaving a note here (was looking at re-implementing the old PR for this) - this code (install_version.R) has always depended on a src/contrib/Meta/archive.rds file, which Artifactory does not create (but could add to it's re-indexing algorithm). If the data in the archive.rds is correct then this works without change. Now that install_version takes a range of versions it is virtually impossible to implement this - without webscraping - until Artifactory changes their system.

I'll also note that Artifactory supports virtual repositories (aka merged repositories) which merge a CRAN mirror with an internal repository - the re-indexing for a virtual repository has to produce a merged version of this data for this to work as well. The data in PACKAGES is merged but the data in Meta/archive.rds is not - it is only from the CRAN mirror.