Ensure that modules load in topological order on both client and server

[philpax]

When a client joins a server, the clientside module entities are sent with client_bytecode_from_url, and these are then processed and loaded in an arbitrary order. This can lead to inconsistent/confusing behaviour, especially as the server creates the corresponding server entities (but does not wait) in topological order, which means the server has some likelihood of working and the client does not.

Ideally, both server and client would load their modules in topological order and guarantee that modules later in the order do not execute before their preceding modules have had a chance to complete their first tick. This is required to ensure that cross-module state sharing works as expected.

It may also be a good idea to define a known order for each level of the topological sort, so that the modules will always load in the same order (i.e. if A, B are depended upon by C, it will always load as A, B, C, and never B, A, C). The sort criteria might be a little confusing, though, especially as multiple packages can load the same dependency and might disagree on the ordering in use.

Open questions:

1. How does this work with hotloading packages? Is there an issue here? My immediate feeling is "no" - loading a package at runtime will also load all of its dependents in the right order - but if multiple packages are hotloaded at the same time, we would want to ensure that they behave correctly.
2. How much do we want to couple WASM modules with packages? In the future, I'd like to be able to spawn WASM modules that are decoupled from packages as workers or actors. What would the topological sort mean there? I think this would also be fine (runtime-spawned modules would be able to rely on their parent package having been loaded), but it may be possible to construct a failure case here.