Add an internal token to all APIs that create resources

[Nadrieril]

This makes it explicit which parts of the game need to be careful about resource handling. Also makes it possible to remove the FooEx traits since they were only needed to avoid making these methods available via the main game crate.

The first 3 commits are from #78.

[albertsgarde]

Was is the advantage of this design over the current privacy based design?
Would it be possible to remove RecipeEx in the current design?

[Nadrieril]

I don't think we can remove RecipeEx in the current design (not without adding the MultiBundleEx bounds by hand). The benefits of this PR are in my view:

1. I find things easier to follow with a single trait, we can even put iter and iter_mut side-by-side despite one being private.
2. I find it super nice to explicitly mark the places where we have to be careful about resource counts, knowing that in other places we can trust the type system;
3. Look how cute the StartingResources trait is now: it makes explicit that it's ok to create resources out of thin air when setting up the game, but prevents holding onto that capability beyond that one function.

[albertsgarde]

That makes a lot of sense. Could we just make the functions that create resources unsafe directly? Feels like this would even more directly mark where we have to be careful, and should have the same advantages wrt. simplifying traits right?

[Nadrieril]

Hm, that's true but you'll note that I don't require unsafe to create the token from within the engine itself. Passing the token feels more robust? We couldn't have the nice StartingResources with just unsafe functions for example.

[albertsgarde]

Oh wow yeah StartingResources does get really nice.

That makes sense. I guess the partial use of unsafe feels weird? That something is safe in one crate is unsafe in another? I know we're already abusing unsafe, but this feels like an unnecessary departure from (at least my impression of) how unsafe usually works. To avoid this we could expose engine_token from the engine. I feel that having unsafe around the token creation doesn't really signal where the dangerous part is anyway, instead it's the usage of the token that does that, which we will still have. Curious to hear what you have to say to this.

Minor things:

1. I would prefer using the full work token to abbreviating it as tk.
2. Given the token specifically breaks the scarcity constraint and not e.g. the time travel constraint, it would make sense to have a name that reflects that. CreationToken, ScarcityExcemptionToken and InfinityToken are the best I/Claude could come up with. Not entirely happy with any, but CreationToken is my current favourite.
3. I think in other places we use #[non_exhuastive] instead of making it a tuple struct.
4. Any reason engine_token returns a &'static EngineToken while EngineToken::make returns a EngineToken? Intuitively we should either always give a &'static EngineToken or give a EngineToken and make it Copy (unless there's some scenario where we want to "use it up"? Seems unlikely given that it's already cheating).
5. All methods visible to the player that use a token should have documentation saying clearly that they are "cheat functions" or whatever. They need to be discoverable by modders, so we can't doc hide them, but it should also be very clear that they are not supposed to go looking for how to get a token. This should also be clearly stated on the doc of the token itself.

[Nadrieril]

I feel that having unsafe around the token creation doesn't really signal where the dangerous part is anyway, instead it's the usage of the token that does that, which we will still have.

Honestly yeah that feels fine. That still gets all the benefits of a token, I do agree it feels off to call that unsafe.

Given the token specifically breaks the scarcity constraint and not e.g. the time travel constraint, it would make sense to have a name that reflects that.

I like CreationToken.

All methods visible to the player that use a token should have documentation saying clearly that they are "cheat functions" or whatever. They need to be discoverable by modders, so we can't doc hide them, but it should also be very clear that they are not supposed to go looking for how to get a token. This should also be clearly stated on the doc of the token itself.

Oh interesting, good point.

I'll look into all that

[albertsgarde]

TokenOfCreation could be fun. Makes it feel magical, which is out of place in the current aesthetic, but that makes sense for a cheat item