Motivation / Problem

Fixes #7513 which is a stack overflow due to recursive marking for garbage collection. Whacking that mole yields a stack overflow due to recursive releasing, so that's tackled here as well.

Description

The bug is solved by rewriting bits of code to go from a recursive marking and releasing to an approach that is more iterative, which is done by having a queue of objects that need to be processed and going through that queue iteratively. Whenever the iterative step on an object requires the same step to be taken on another object (release or GC marking), then that object is added to the queue so it will be processed at a later stage.

Limitations

Depending on the code, now you might hit out of memory issues instead of the game crashing due to a stack overflow. I intentionally tried to make a few changes to the rest of the squirrel code, so it's probably not all according to coding style. I rather leave the coding style fixes for Squirrel for another time, as not doing those makes it easier to see the differences between stock and our version of squirrel.
Freeing and GC marking can cause lags with such large amounts of elements, but that's inherent to such massive amounts of elements; millions in my test cases in debug builds. This makes both freeing and GC marking slightly slower, but the benefit is the game not crashing.

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 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