Detect family name when having Mega Energy or Candy XL

[xZise]

When there is Mega Energy or Candy XL for the Pokémon the current recognition doesn't really work anymore.

Originally it was always this:

+-----------------+--------------+
|    Stardust     |     Candy    |
+-----------------+--------------+

When Mega Energy was introduced it was displayed in three columns. Additionally it doesn't use the family name for the Mega Energy but instead the name of the Pokémon to be evolved. So it would be "Snover Candy" but "Abomasnow Mega Energy". It would also split the name into two lines usually.

+----------+-------+-------------+
| Stardust | Candy | Mega Energy |
+----------+-------+-------------+

It could also be in the following form:

+-----------+--------+-----------+
| Stardust  | Candy  | Candy XL  |
+-----------+--------+-----------+

And lastly if all four items are present they are presented in a 2 by 2 grid:

+-----------------+--------------+
|    Stardust     |     Candy    |
+-----------------+--------------+
|    Candy XL     |  Mega Energy |
+-----------------+--------------+

[lramati]

I Think we can solve this with a minor refactor. Right now, the flow of data is that OcrHelper::getCandyNameFromImg returns a single string it thinks is the candy name, and then that eventually gets sent to PokemonNameCorrector::guessBestPokemonByNormalizedName to try and match it to an actual pokemon name.

The refactor would make it so that getCandyNameFromImg would return a list of scan attempts, to try and cover all the options. Then guessBestPokemonByNormalizedName would compare the quality of the best match for each of these attempts and return the optimal one. Then, in case it was a Mega Energy pokemon name, we'd run it through the evolutionCandyName resource to get the actual candy name. This presents several problems:

1. We need a method for ranking the quality of matches. It's possible that the current levenshtein distance used to compare the different pokemon to the same attempt string will work, but also maybe not? We'd need to test this and find out for sure.
2. We need a way to take a single calibration scan and create the bounding boxes for all the potential scan locations. I think we don't actually need to take care of all of them individually, as Candy + Mega is very similar to Candy + XL, and Only Candy is reasonably similar to Candy XL + Mega. Even if we only need the two configurations, we should find a way to generate both from any of the potential screenshots. I think we can request that the calibration scan not be of a pokemon with all the fields, as there's not actually that many Pokemon with megas.
3. Either way, we need to add yet another potential offset to the scanning logic to account for the second row with XL and Mega in the everything case.

[lramati]

Re 2: I think we can make this work by using the current calibration logic to find the horizontal slice of screen that needs to be checked, and then using the middle third for the 3 item case, and using the right half for the 2 and 4 item cases. I'll try to mock it up and do some tests