feat: extend add_spawn() to handle creating pets

[ekaratzas]

So far map::add_spawn() and the underlying spawn_point struct have been operating on the binary notion that a spawn can be friendly or not. This PR extends those APIs to also support generating monsters that are pets of the player, while also honoring backwards compatibility with parts of the codebase that still want to operate on the binary friendly notion, such as the save/load system for submaps.

Purpose of change

This is a followup to previous PRs (#4287, #4289) that made it possible for friendly wildlife creatures to spawn friendly offspring, mostly as a QoL improvement for farm players. As chaosvolt point out, this ended up creating friendly offspring, not pets. Hence several functions such as slaughter, milk, etc were still not allowed for friendly offspring - the player has to manually tame the friendly creatures to make them full blown pets. This PR addresses that so that wildlife pets of the player will actually spawn offspring that are full blown pets.

Describe the solution

The map::add_spawn() API, backed up by the spawn_point structure, operated under the binary notion of spawning friendly or not friendly monsters. spawn_point and submap::spawns in general is used to keep track of monsters that are about to be spawned by haven't spawned yet - e.g. spawning creatures while loading new submap for first time or spawning baby chicken from egg, etc.

This PR takes care to extend this API with an enum while also preserving backwards compatibility with legacy systems such as the save/load part of submaps which need to keep operating with a binary notion of friendly so as to not break old save games. However, this doesn't prevent us from extending the API in order to be able to handle creating pet -or even monsters with other, unique dispositions- in the future via map::add_spawn().

The only corner-case where this patch wouldn't work as expected is in the unlikely corner-case where a creature is added to submap::spawns but is not spawned yet and the player saves+exits the game, at which point fine grained information of disposition is lost and we just save the 'spawn' in the submap save file as either friendly or not friendly in order to be backwards compatible.

IMHO the patch is as noninvasive as it can possibly be while still accomplishing the desired effect, looking forward to feedback though.

Describe alternatives you've considered

I've considered extending the attitude enum with a pet disposition and using that in spawn_point struct, but it seemed like a bad idea. I think a more narrowly scoped enum makes more sense for this case.

Testing

I've tested creating offspring with this patch and then ensuring that when they spawn, in the pet menu i can actually do things like 'slaughter' which I couldn't before since they just spawned as friendly.

This commit has been used to ease testing by making offspring spawn during submap load(), it applies on top of this patch. be944e8

Additional context

Checklist

[ekaratzas]

@chaosvolt could you please take a look when you get as second?

[chaosvolt]

Oh hecc, nice. Will test out tomorrow since is late on my end currently.

[scarf005]

we really need some debug command to refresh map/force rot/hatch all visible items

[ekaratzas]

we really need some debug command to refresh map/force rot/hatch all visible items

Yes that is a great point. I can look into that.