Allow mission descriptions to refer to the effects of the mission.

[Petethegoat]

SUMMARY: Interface "Allow mission descriptions to refer to the effects of the mission."

Purpose of change

Make written mission descriptions more resilient to becoming outdated if they want to refer to eg. the rewards provided by the mission.

Describe the solution

talk_effect_fun_t now has a simple and specific structure to store likely mission rewards, and it fills this during json loading. mission_type then grabs this and stores it for use by the mission UI later, using simple string replacement.
Currently it's limited to looking for the "u_buy_item" effect, and only when the cost is 0 (unspecified defaults to 0).

The tokens in descriptions look like this: "<reward_count:FMCNote>"
They'll look for a "u_buy_item" effect with a matching item id, and replace the whole token with the count for that item.
This does work correctly for multiple tokens in a single description. So you can reward several things and refer to all their counts correctly.

Describe alternatives you've considered

This is very specific for things that are probably rewards for the mission only- but it's kept it relatively simple rather than trying to guess future use-cases ahead of time, so refactoring it to include other parameters shouldn't be too painful, if need be.

Additional context

Created for #33325.

[Petethegoat]

To be clear, it's the stuff in mission_util.cpp that makes me question if this is something usable. Maybe that can be implemented more generically somehow, but I don't have any particularly bright ideas regarding that.

[Petethegoat]

@ralreegorganon suggested a much less boneheaded way of getting the effect data that I've now implemented, which makes this feel a lot less hacky.

Right now I'm still putting the data into a very specific structure that's probably only going to be useful for my use case.
I'm not sure if I should try to generalize it without really knowing what other people will need, or if I should just keep it simple so someone who knows what they want can easily refactor it in the future.

Leaning towards the latter, lazier option, but I'm open to suggestions.

[BevapDin]

There needs to be at least once instance that actually uses the new code, so we can see it works as expected. And documentation in some file in the "doc" folder would be nice (when it's finished).

[Petethegoat]

@BevapDin Kevin accidentally merged my Free Merchant descriptions PR that was supposed to wait for this, so there's already descriptions using this in master.

Will work on docs next, and then I think I'm happy with this, assuming the laziness regarding generalizing this is acceptable 🙂

[Petethegoat]

Docs added and PR description updated.

[ZhilkinSerg]

Some conflicts creeped in. Can you resolve them please?

[Petethegoat]

Will do shortly.

[Petethegoat]

@ZhilkinSerg done, thanks for the heads up. :)