More freedom in Loop state, add Loop:setWorlds()

[jackTabsCode]

Right now, there's a few issues with how the Loop and Debugger handle Worlds.

• The Loop naively looks at its state to determine which values are Worlds, so it can buffer commands from systems.
• The Debugger naively looks at the Loop's state to determine which values are Worlds, so it can render the appropriate widget. Additionally, it only supports one World which is stored in debugWorld for use cases like hover inspect and entity inspect.

In my game, I'd like to have a single loop parameter which is a class that contains both the world and other states. This is impossible due to the problems mentioned above, and it would break both the debugger, and Loop command buffering.

I propose an API Loop:setWorlds(worlds: {World} | {[string]: World}). This would be a breaking change-users would need to call this before calling Loop:begin(...), though it is a very easy change for users. worlds can be either an array of Worlds, or a dictionary (if they want to call the Worlds something else in the debugger). This allows both the Debugger and the Loop to know exactly what Worlds it can use without further introspection.