Keep historical Plugins/Themes/Packages #392
Description
Both PHP and Postgres have an elephant for their mascot, and AspireCloud is based on both of them, yet it still does a lot of forgetting. Namely, whenever AC receives new metadata for an existing plugin or theme, it completely replaces the old data with a new copy. We might be using immutable rows, but it may as well be mutable data for all the lack of persistence. It's even worse with ClosedPlugin, which destroys the old Plugin and replaces it with a bare stub of metadata, no longer enough to create a real Package object for.
One thing I won't consider is to simply use soft deletes and leaving it at that: I would prefer either separate historical tables and a view to join them, or if we do enable soft-deletes, basing our model class off a view with appropriate functional indexes defined. Both approaches preclude being able to instantiate model instances of deleted rows (that is, withTrashed() is not happening), but if we switched to mapping custom DTOs instead of chaining ourselves to Eloquent, this problem vanishes. As long as we continue to keep models read-only, both approaches are much simpler than they would be otherwise.
Relates to #391 which would benefit greatly from having this historical data.