CardPool now includes the logic to (a) retrieve the edition frequency map of itself, as well as retrieving its corresponding PivotEdition (depending on cards in the pool).
This refactoring optimises the code in Deck class for "smartCardArt" selection
`getTheLatestOfAllTheOriginalEditionsOfCardsIn` is the new name for `getEarliestEditionWithAllCards` which better clarifies the intent of the method.
The implementation has been optimised, according to the new CardDb behaviour and APIs.
The tests have been extended to verify that the output of the method is always consistent regardless of the edition of cards in the input CardPool.
This method will be also re-used in Decks when inspecting the list of cards to add in a Deck Section.
This refactoring avoids code duplications, and improves modularization.
New tests (and fixed updated CardRequest implementation) verify that any method used for Card Retrieval when receiving directly CardRequest formatted strings as cardName won't have any side effect. In particular, the code is reliable to be robust enough to support passing in both card name (only) or a full cardRequest string.
If the latter, any parameter in the request will be updated - accordingly - only when explicit params in function calls are provided.
Also, new tests demonstrate that the current implementation has NO side effect when testing for multiple combinations. Therefore, whatever is requested in requestString won't be overruled, unless really requested too.
Clarified (imho) a ton my own previous wording about this option - also for Italian. Moreover, this update aligns all the "RESTART REQUIRED" labels with the same translation and case.
Also, it is important to emphasise that previous implementation of the "Strict" Card Art Preference policy were too stringent, and did not account for corner cases when the card could not be retrieved. This has been FIXED in the new API implementation.
Huge refactoring in variable names and test case optimisations. Also, new tests for the new API are also included. In particular, additional corner cases tested, as well as verification with Legacy (previous) CardDb implementation.
