historical versions + downgrading packages

[vgmoose]

Historical versions of all packages and older versions on the store would be useful for troubleshooting and ensuring that updating isn't a risky procedure as packages could be downgraded

I didn't think that this would be necessary when this project started, but as it goes on it becomes apparent that having such functionality would be very useful. Especially seeing our changelog field grow and become unmanageable.

Steps to take:

• making the repo.json index lighter, excluding long details and changelogs, and only pointing to the "latest" version of the app. It should also list the total versions of historical versions available for older apps
• asynchronous loading of current details/description
• installing specific versions of packages
• depending on specific versions of packages

One potential approach would be to make each package have an archive folder containing folders named starting with 0 and incrementing as high as possible (these would be acting as "Build numbers" and could only ever increase). Inside, would be contained the exact contents of the old package, info.json and whatever files are needing.

This would effectively allow the client to know how many old versions are available, and request the descriptions on the fly for the user to choose between

It would also be nice to employ caching on the client, so that that version selector list could include the changelogs without having to make additional rest requests.

[vgmoose]

incremental version numbers wouldn't have to be only for historical versions, @rw-r-r-0644 pointed out they could also be stored in the info.json so that the client knows immediately if their package is outdated without treating it as needing an update (since currently version numbers are only strings)