What can we do with the new worlds property of the project-config-standard?

[Nusiq]

New property was added to the project-config-standard recently. Maybe we should pass that information to the filters somehow:
Bedrock-OSS/project-config-standard#2

[arexon]

I think this would be a good opportunity to implement a way to test/save worlds by having a single source of truth for them in the project root, preferably in a worlds folder alongside packs.

The way this could work is that we would have a regolith world subcommand with a couple of flags:

• --test <name>: test the specified world by copying it from the project root to minecraftWorlds
• --save <name>: save the specified world by copying it from minecraftWorlds to the project root

Another alternative could be regolith test-world <name> and regolith save-world <name> instead of flags.

I should note that an unwanted behavior with this implementation could be how overwriting is handled. Do we want both testing and saving to overwrite an already existing world, or maybe disable overwriting by default and add a flag to enable it?

Possible Caveat

Now unfortunately, because of how project-config-standard standardizes the worlds property, we would be unable to define a short name for a world path to be used by regolith. For instance:

{
  "worlds": [
    {
      "short": "worlds/long_name"
    }
  ]
}

I'm not sure everybody would be up to change the standard, but with the way it is currently, we would have to use the array index. I.e. regolith world --test 1

Edit: We could also use the worldTemplate property in packs to allow users to define a path for where worlds should be stored. With that path, we can make each world folder name an analogue for the short name:

{
  "packs": {
    "worldTemplate": "./packs/WT"
  }
}

So for instance, assuming a world named "foobar" is stored in the above path, we can test it with regolith world --test foobar.

This may not be the best alternative, but it gets rid of the short name issue.