Extend requirement groups

[dseguin]

Summary

None

Purpose of change

LyleSY ran into a limitation of requirements in #56319:

Requirement groups can only be overwritten, meaning that two mods modifying the same requirement id will overwrite each other.

Describe the solution

Add an optional field to requirements to extend the list:

{
  "id": "bone_sturdy",
  "type": "requirement",
  "extend": { "components": [ [ [ "frost_bone_human", 1 ], [ "alien_bone", 1 ] ] ] }
}

Using "extend" causes the currently loaded requirement to integrate the given list.

Describe alternatives you've considered

This could be implemented as a set of requirements per id (one for each src), but that would require a significant overhaul of the rest of the codebase. This is just the simplest option.

I also tried making requirements extend by default, but inline requirement id's (generated at load time) tend to cause problems. There's no clean way to distinguish a generated id from a manually created id (other than the prefix on generated id's).

Testing

Added some test cases to check that extended requirements are properly added:

./tests/cata_test -d yes --rng-seed time "requirement_extension"

Manual testing: Loading a recipe that extends eggs_bird for DinoMod and Magiclysm.

Additional context

TODO:

• Implement "extending"
• Update requirements in mods
• Use extend syntax (thanks Maddremor)
• Update documentation
• Testing

[Maddremor]

I'm sure there is a good reason for this, but why not use the copy-from and extend syntax?

[dseguin]

I'm sure there is a good reason for this, but why not use the copy-from and extend syntax?

I guess I didn't think of it :P

I'm pretty sure those are provided by generic_factory, which won't work by itself in this case. But I can make it look like the normal extend syntax, which should work like you'd expect.

[Maleclypse]

This looks good for the aftershock changes. Thank you this is really cool!

[LyleSY]

Love it thanks!

[LyleSY]

Failed monster attack test doesn't look related