Refactor packs logic

[paulchambaz]

The current pack logic was hastely added and is poorly thought out. In truth it is in need of a refactor, in particular three new features are required.

First, users complain that it is not clear, especially on mobile, if the button has been pressed. To fix that, we should add a count (composed of the minimum of the capacity of the stacks present in the pack). That was, a user press should result in a number decreasing, which should be clearer for the user. To add this feature, we must first add to the libpolybase the feature to enumerate all the details of the polys of a pack. This feature can then be used in the web frontend to showcase that information.

Second, users complain that besides color codes, the content of a pack is not clear. To fix that, we should add on hover over the poly badges a detailed description containing the full content that are present on the cards. To add this feature, we should reuse the function developped for the first point that enumerate all the contents of a given pack then use it to showcase on the web frontend.

Third, many packs are created around a given code, so the concept of a UE packs should be introduced. The current packs should be renamed Mega packs, or some other names in the web frontend. UE packs should be automatically generated (or adjusted) when a poly stack is added. This way, users of polybase should interact first with Mega packs (pack L1), then with UE packs, and then, as a last resort, with the polys themselves. To do this, a refactor of the frontend to clearly show these three sections (removing the possibility to edit a UE pack for example), and then writing the logic to automatically deduce the list of UE packs from the current poly stacks in a functional, deterministic way, with as few database operations as possible.