Forge loads all files found on the setlookup folder.
Example J21.txt (J21 set code) contains a list of set codes (sorted from Newest to Oldest beforehand) to lookup for images on other sets.
getUnique previously returned random results, based on the internal order in which entries were found.
Now, filtering by Unique Cards in Catalog is aware of the current Cart Art Preference
Also, the algorithm takes into account the case in which card image is missing.
In that case, the method tries to fill in the gaps with those alternatives having images. If not possible, the original entries are returned.
DeckChooser uses it's own `selectedDeckType` to get current selected deck type (instead of querying it from deckComboBox) to update forge perferences, accordingly.
Most of this commit is for code formatting and cleaning. Major changes include the use fo getAlternativeCardPrint from Static Data (using the same policy that was used before) and the use of the `getTheLatestOfAllEditionsForCardsIn` method :D
`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.
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.
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.
