add copy_to argument to createworld command

[BehrRiley]

Summary

this pull request adds a new copy_to argument to the createworld command, allowing scripters to specify custom destination folder paths. this fixes pathing conflicts when initializing or copying worlds into modern datapack dimension subdirectories (eg, world/dimensions/minecraft/...).

Problem

when using createworld with copy_from, we previously locked the file destination path directly to the server root using Bukkit.getWorldContainer() plus the world name; with modern vanilla and Paper datapack dimensions, Bukkit initializes the dimension inside nested subfolders while Denizen was copying files to the root directory, completely ignoring the template files. the strict forbiddenSymbols security check was rejecting any paths containing forward slashes (/), stopping scripters from passing normalized subdirectories entirely also which is going to be very necessary with world path formatting.

Testing

• Tested on the latest supported patch-versions
• Verified copy_to correctly redirects file operations and lock cleanup (eg, uid.dat, session.lock) to the custom folder path while preserving standard Bukkit world registration
  used various testing examples:
• ~createworld test_dimension copy_from:my_template copy_to:world/dimensions/minecraft/test_dimension
• ~createworld mwtown_city copy_from:world/dimensions/minecraft/the_end environment:THE_END copy_to:world/dimensions/something/mwtown_city;

here's a startup log referencing this test with tags parsed for verification:
https://files.behr.dev/file-share/createworld-copy-to-branch-latest.log

A working build of my latest successful build which has no errors can be built with this branch or found at:
https://files.behr.dev/file-share/denizen-createworld-copy-to.jar

[mcmonkey4eva]

This seems wrong at a fundamental level. Path should be implicit from data input and logical process from there.
(In old code this is literally root/{name}, in new Minecraft ... I don't know the exact rules, but something like root/{name}/dimensions/{dimension}?)

Remember that createworld is also the load world command, and also the create without copying anything command. It needs to work equally and beautifully for all cases.

[BehrRiley]

(In old code this is literally root/{name}, in new Minecraft ... I don't know the exact rules, but something like root/{name}/dimensions/{dimension}?

the new layout is actually why I added the : handling here; with the 26.1 world storage changes, namespaced dimensions get stored under the world's folder as dimensions/<namespace>/<dimension>. eg, minecraft:lasagna would be world/dimensions/minecraft/lasagna, rather than just root/minecraft:lasagna; mwthorn's thread has another example.

should i check if they specify the namespace, handle it differently for >26.1, or something else?

[BehrRiley]

(In old code this is literally root/{name}, in new Minecraft ... I don't know the exact rules, but something like root/{name}/dimensions/{dimension}?

the new layout is actually why I added the : handling here; with the 26.1 world storage changes, namespaced dimensions get stored under the world's folder as dimensions/<namespace>/<dimension>. eg, minecraft:lasagna would be world/dimensions/minecraft/lasagna, rather than just root/minecraft:lasagna; mwthorn's thread has another example.

should i check if they specify the namespace, handle it differently for >26.1, or something else?

i know i can do either of of always infer the destination from the world name / namespace or infer namespaced dimensions while keeping normal worlds unchanged, i've decided to do the latter