This refactors the ship registry and the OSWPT struct to store data as indexes rather than pointers. This is a prerequisite for making these collections dynamic in the future. See also #5800.
This advances the versions for Clang to 16 and GCC to 13 along with
fixing any warnings these new versions are detecting now.
The new image versions also include Vulkan so the additional workflow
step for installing that is not necessary anymore.
One of the features requested in #5378 (specifically the one requested in #5274), this adds a new "$Contrails use absolute speed:" option to game_settings.tbl, which makes the `ct_below_limit()` function check `objp->phys_info.speed` instead of `objp->phys_info.fspeed`. This allows contrails to appear when moving in a direction other than forwards.
This option was misleadingly named when originally introduced, so give it a more sensible name. The old name is still accepted for backwards compatibility.
Here's some low-hanging fruit for reducing the memory footprint of `ship_info`. This turns the maneuvering thrusters array into a vector, refactors the names a bit, fixes thruster activation when `-nosound` is active, reduces the number of calls to `ship_get_thruster_status`, adds some const-correctness, and converts the timestamps to the new system.
In many calls to `ship_get_subsystem_strength`, the caller doesn't care about the actual number, just whether the subsystem type is destroyed. So this adds an optimization to check specifically for that. In the case of `SUBSYSTEM_ENGINE`, this avoids an iteration over every subsystem on the ship which, for a ship with many turrets, can be significant.
Some of the `frand_range` calls were used for integer calculations, so we can use `Random::next` now.
This also reduces the number of C-style casts in the codebase.
Add `const` to the `eval_enemy_obj_struct` struct so its values aren't inadvertently overwritten. Handle a bit of const-correctness propagation. Also add default member initialization to the struct.
This is an actual edge case bug. If no countermeasure was set, and then one was set, there might be a garbage timestamp set that would give an incorrect countermeasure delay on next use.
A mission in Mantle caused an invalid vector access when checking whether to vaporize a ship whose ship type was -1. Turns out having "no type" is actually allowed, so I audited all `class_type` accesses throughout the code for potential -1 accesses. Most were properly checked but a few were not. A few others needed to be tweaked.
(I suspect this is something that would be on the Coverity list if it isn't already.)
Goober5000