feat(std-contracts): add SystemCallbackComponent

[dk1a]

FunctionComponent:

• Stores an arbitrary contract's address and a selector to one of its functions.
• You use staticcallFunctionSelector with your own arguments to that function.
• If the contract address is a system, an outdated version of it could get called, which could make maintaining a FunctionComponent troublesome.

SystemCallbackComponent:

• Stores a system ID and the arguments for that specific system's execute (note how no address is stored).
• You use executeSystemCallback with your own IWorld address. You do NOT use your own arguments (although technically you could, but that seems like an antipattern).
• Maintaining a SystemCallbackComponent gets troublesome only if the system's arguments change. Otherwise the system's logic can change seamlessly.
• You do not need to know which system the callback calls, or what the arguments are (however you can inspect them if you want to).

This is designed primarily with Subsystems in mind, however it technically works with any systems and doesn't depend on #268

[alvrs]

I like this idea! For posterity, could you elaborate on a specific use case you have in mind?

[dk1a]

About time to make https://github.com/dk1a/wanderer-cycle public, hard to explain some of my PRs without it. Do note it's still extremely unfinished.
I have ScopedDurationSubsystem and EffectSubsystem
Effect's executeApplyTimed calls Duration's executeIncrease and sets the onEnd callback to be Effect's executeRemove. Note how Duration is in another repo and is completely unaware of Effect. This lets me do real callbacks without any hardcoded circular dependencies

[alvrs]

Great addition! 🚢

[holic]

It'd be great to find an easy-to-understand use case that we can document alongside this!

[dk1a]

@alvrs Oh, you merged it faster than I expected. Was gonna change it to account for #327. Do you want me to do a breaking change PR for this component soon-ish, or leave that for v2?

[alvrs]

I assume you're referring to removing the requirement for an execute method? Since that's a breaking change anyway I'd leave it for v2. This PR seemed useful for v1 already though.