In migrating away from depending on the active mod loading context, Balm was switched to use the mod id from the object being registered to determine the mod bus event to register under.

This came with some downsides:

• Every method depending on a mod event bus needs an identifier parameter, even when it would feel out of place - the API shouldn't need to change just because an upstream implementation changed to rely on the mod event bus
• Adding items to creative tabs would need two identifiers, one for the registrant and one for the target creative tab, because the creative tab identifier may not be registered through Balm but building creative tabs runs on mod event bus

A possible solution is scoping Balm services under a mod id.

• Service impls take a context resolver, defaulting to using the registry object's namespace
• BalmBlocks.scoped(String modId) -> ScopedBalmBlocks (BalmBlocks impl. that is setup with a different context resolver)
• Services passed to BalmModules can be scoped by default
• Registering under a scope that was not initialized with Balm should crash if it needs a mod event bus to function (right now it will essentially no-op, so I think it's a fair breaking change to lure out potential bugs)
• Possible further cleanup in 1.22 to better separate unscoped from scoped services (like defaulting to the scoped interface for BalmModules and discouraging use of the unscoped service)