Add Johto safari zone encounters

[Machine-Maker]

Change description

Adds gen iv Johto safari zone encounters
Closes #1522

AI coding assistance disclosure

Claude helped me understand the decompiled codebase for heartgold. And to design a script that would generate all the encounter lines.

Contributor check list

• I have written a description of the contribution and explained its motivation.
• I have written tests for my code changes (if applicable).
• I have read and understood the AI Assisted Contribution guidelines.
• I will own this change in production, and I am prepared to fix any bugs caused by my code change.

[jemarq04]

Can you provide more of a description to what you're adding? What I'm reading on Bulbapedia does not match what you're adding here.

For example, Fearow isn't available in johto-safari-zone-peak unless there are 5 Forest block objects placed in it, according to Bulbapedia. However, this PR just adds a johto-safari-displaced with prose "Displaced by block-based encounter". This doesn't seem very clear to me (and I'm not sure what is even meant by "displaced").

Some encounters require multiple types of blocks, so maybe something more reasonable would be a set of encounter conditions - one for each type of block object that would need to be placed. Then a set of relevant condition values would be added (e.g. a johto-safari-forest-block condition with a johto-safari-forest-block-5 condition value for Fearow's, or something like this). I think this would make things a lot clearer as to how we would encounter these pokemon in the area

Also.. "Claude helped" is not much of a description for how you used AI to aid this PR. You've added a lot of helpful encounters we've missed, so thank you for that, but please try to be descriptive in these descriptions so we know what we're reviewing

[Machine-Maker]

I adjusted the ai disclosure statement.

As for the encounter structure, I originally tried to model the block count requirement for each pokemon, but that quickly got out of hand, especially with so many different combinations. Some pokemon require amounts of 2 different blocks as well which only further compounds the issue.

So I decided, at least for now, to go back and simplify it. I would just have one new encounter condition type with 2 values, "displaced" or "not displaced". You need some condition on the base encounters for each safari zone biome that says this encounter can be turned off, or "displaced" by a block-based encounter. You don't technically need this for all the base encounters for each area, but there's not a good way of knowing which you do, and which you don't. The base encounters are replaced by block-based encounters just in the order the base encounters are stored in, one-by-one as new block-based encounters are activated.

As usual it seems, my naming can be a bit off and I suppose while I was working on it, "displaced" just seemed to be natural to me, but of course I am open to alternatives. I've made some changes already, and can make more.

It basically comes down to us needing 2 condition values, one to say that this encounter (a base encounter in an area) can be turned off if its replaced by one of the block-based encounters. And we need another condition value that says this encounter is only activated by placing various blocks (without having to model the exact block requirements).