Dome bug fix: enemy stats incorrectly calculated

[MagpieLaboratories]

Two very straightforward changes:

• The CALC_STAT u8 cast is clearly a bug and I'm guessing maybe caused by a compiler.
• bits not being reset is likely a bug by the devs and I guess its easy to miss. After shifting bits this much, the next loop is useless.

One slightly less simple change:

• The function SetFacilityPtrsGetLevel() - looks at the players entire party. So if I have 4 pokemon of level: 60,60,60,100 - it will return 100
• This is a problem because if i selected the pokemon of level 60,60,60 - my highest level is 60 for the challenge
• The game will incorrectly use 100 for all the rest of the seeding calculations
• This bug only exists for Open Level, not Level 50
• The fix I've proposed felt like a reasonable compromise between being easily readable, not being too long, and not bringing in too many global functions. I'm not that familiar with the code style in PRET though.

There is no "direct" effect on gameplay in battles, but this is used:

• To calculate enemy seeding positions
• (In part) to determine the result of enemy vs enemy "matches"

Without the bug fixes:

• Enemies never have any EVs at all in the seeding calculations - an advantage of 64-127 seeding/ranking points depending on the Level played at
• Any non-HP enemy stat larger than 255 (remember that with the EV bug above, this is kind-of rare to hit) will overflow, which is effectively -255 to the seeding score each time it happens to any pokemon.
• If the player unknowingly has run into the SetFacilityPtrsGetLevel bug because of their party; then this is obviously potentially a massive disadvantage and could completely ruin the player's seeding despite the bugs above.

Dome seeding is not that important for typical casual play, however the way in which a tie forces the higher seed to win does matter for gameplay purposes and this is affecting that.

[GriffinRichards]

Your changes don't compile, you're using #ifdef inside a #define.