Core: Multiple-game or non-game expansion for manifest

[duckboycool]

What feature would you like to see?

Currently with the manifest/apworld spec, things work off of the assumption that .apworlds will contain exactly one World in them, which is what the fields all refer to. This has caused some friction for both non-world tools released as an .apworld (which is probably a good way to release these otherwise) and also multiple world classes within one .apworld package with Pokemon for instance. I think both of these cases are worth addressing, and to me these seem like good ways without having to change too much of the current system:

• For non-Worlds, they can put "game": null into the manifest to indicate this. This already seemingly works okay (and got some agreement as a way to handle this case when it's been discussed in the discord before), but this should be given explicit mention in the docs and the APWorld builder tool should be reworked so that it can package these since currently it just goes through world_types (and so you have to manually put what I'm pretty sure are meaningless version/compatible_version given they're not actually APWorldContainers). Potentially they could also be given a separate extension like .aptool if that seems desirable.
• For multi-Worlds, as an alternative to Core: Allow multiple games per APWorld #6233, I think it may be better to stick to keeping a single World allowed and instead introduce a separate "world" type that the common parts can be separated out to as a dependency of the .apworlds (feasible from Core: Do not process datapackage attributes for abstract world subclasses #5468 improving support for "abstract" worlds with no game set). I think this one should get its own extension, say something like .apdep. This keeps the manifest handling for worlds simpler and also more flexible since worlds shipped this way can also have separate fields like authors without having to also add some way to indicate which belongs to which world. It also means that updates for either the core or the dependent worlds can be made separately if wanted, and if there's a nontrivial amount of per-world information, users using only one of them don't have to download it. I also think that keeping to a one world per .apworld system might be simpler for players/hosts as well (although there might be some issues with players handling the dependencies themselves). Core has also mentioned something similar as a possible way to handle common external dependencies for custom worlds, and this could be a better way to ensure things needed by worlds are loaded first, like _bizhawk or generic.

[Silvris]

Relevant prior discussion on the 2nd matter

[Ixrec]

Another thought on the 2nd matter/.apdeps: In addition to the "shared code" use cases, there has also been some debate over whether large .apworlds (e.g. those providing UT map pages with lots of image files) should be split into multiple apworlds, so that hosts/non-players who only need generation code can get a smaller download. I currently do not think this is worth the cost of user confusion unless it can be made seamless to users via first-class support in a future official package manager.

In other words, if we make an ".apdep" system, I think it should support "optional .apdeps", or at least plan ahead for how they could potentially be supported.

[Miiroun]

In my opinion setting game to none is not desirable since then we cannot track the tools versions. I would prefer if we added a new field to the manifest called "tools" which they could use instead. We could then make the game/tool field optional if the other is present.

[Silvris]

In my opinion setting game to none is not desirable since then we cannot track the tools versions. I would prefer if we added a new field to the manifest called "tools" which they could use instead. We could then make the game/tool field optional if the other is present.

I was thinking we might want to go a step more explicit, and have a separate class ala APClientContainer or something, that way we can load them separate from worlds entirely.