Fix #10469, 5e14a20: [Script] League Table rating element is a int64 everywhere else

[SamuXarick]

Motivation / Problem

Closes #10469
Rating is a int64 in the Cmd functions, in the script API functions, but not on the league table element struct. Sorting through negative values would cause 0 to be below them.

Description

Turn rating in struct into int64, and add savegame bump and conversion.

Limitations

Probably will cause issues if the values saved on an old savegame were already above INT64_MAX to begin with, they would turn negative after load, most likely.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[ldpl]

I don't remember why it ended up with different types. Probably I changed it at some point and missed one place. At the end of the day it's just an arbitrary field only used for sorting so it doesn't matter much what type it is. But as GS types are signed having it stored as signed as well makes more sense. Probably GS methods can even accept SQInteger or whatever is GS type called. But as SQInteger isn't used in other functions yet it's probably fine to leave it as int64 is for this PR.

Also, savegame conversion stuff and version bump is logically redundant as it is just a int64 stored in that uint64 anyway. But I don't know of a better way to express that in the new save format so I guess it's fine as it is.

[glx22]

I don't think any changes in the savegame stuff is needed, using SLE_UINT64 for an int64 should work fine.

[ldpl]

I don't think any changes in the savegame stuff is needed, using SLE_UINT64 for an int64 should work fine.

It feels kinda dumb to have to use a wrong type to bypass a type check.

[rubidium42]

I don't think any changes in the savegame stuff is needed, using SLE_UINT64 for an int64 should work fine.

It feels kinda dumb to have to use a wrong type to bypass a type check.

There is a middle ground solution SLE_VAR(LeagueTableElement, rating, SLE_FILE_U64 | SLE_VAR_I64),, which could be accompanied by a comment that the type in the file is technically wrong, but that a savegame bump is an excessive change. But that, when a savegame bump is required for the LeageTableElement, this should be corrected by a proper change as well.

[glx22]

Backport can only be partial due to savegame bump, but uint64 -> int64 itself can go to release branch I think.

[rubidium42]

Backport can only be partial due to savegame bump, but uint64 -> int64 itself can go to release branch I think.

Hmm, true. How to annotate that for the poor soul that's going to try to backport?