Started with o_seg, s_seg and z_seg arrays

[OnlineCop]

This is my attempt to reduce the number of C-style memory management.

[pedro-w]

On the o_seg et al, might it be nicer to implement a 2D array class to replace those many [(y * g_map.xsize) + x] -type calculations? We already know it can be buggy Something like uint8_t& at(int x, int y); ?

[OnlineCop]

Yes, absolutely. I'm actually working on that now, but I didn't want this PR to become massive. My goal is to actually move everything that has to do with g_map into a wrapper class (KMap or KMapManager) so I could then just pass in the desired tile's coords as a simple (x, y) pair.

I also found a helper to be extremely useful that I've started with in the interim:

constexpr size_t Coords(signed int tile_x, signed int tile_y)
{
    int index = std::clamp(g_map.xsize * tile_y + tile_x, 0U, g_map.xsize * g_map.ysize - 1);
    return index;
}

I'm really liking this constexpr thing that C++17 and later have introduced for functions, as it can inline this just as efficiently as a #define Coords(tile_x, tile_y) ..., but with the added benefit of compile-time type safety.

In the above, I explicitly allow signed integers, since some of the scripts may do some_tile_x + amount_to_move_x logic which COULD sum to a negative value. If I used an unsigned input type, a -1 value would roll around to a large positive value, and we wouldn't want the entity to shoot off to the opposite end of the map.