fix some bugs for run_eoc_until

[PipeYume]

Summary

Bugfixes "fix some bugs for run_eoc_until"

Purpose of change

1. In the documentation, one field is "iteration", but in the code, the checked field is "iteration_count"

2. When the iteration number is too large, a debugmsg occurs within eoc->activate due to the callstack of dialogue being too large.

3. The condition of run_eoc_until can only be set in advance using set_condition. I don't understand the significance of this. Can't we just use the condition syntax directly?

Describe the solution

1. I changed the "iteration_count" in the code to "iteration".

2. Add a bool value require_callstack_check in eoc->activate to determine whether to amend the eoc in the callstack and check the size of callstack. Then, in run_eoc_until, amend one eoc into the callstack instead of amending several eocs into the callstack repeatedly in the iteration.

3. use condition syntax directly.

Describe alternatives you've considered

Testing

Test function is updated.

Additional context

[GuardianDll]

I think p.3 was made with idea that it would be possible to use said conditions as a separate json object, tho now we have #71956 which solves it from another direction

[PipeYume]

I think p.3 was made with idea that it would be possible to use said conditions as a separate json object, tho now we have #71956 which solves it from another direction

get_condition could be able to achieve the functionality of using the same condition across different EOCs I think.
get_condition can only retrieve the condition in a dialogue that has been set by set_condition (

In p3, I actually meant to express that the previous run_eoc_until could only use the condition specified by set_condition and could not directly use the common condition syntax.
(The original "condition": "a name" is equivalent to "condition": {"get_condition": "a name"}. Common condition syntax can also load the condition. )