Expand API classes exposed to modules

[BenjaminAmos]

Description

This pull request fixes some of the issues with code modules currently by exposing the new ECS classes as API classes, as well as the GameOptions class, which was omitted previously. It also fixes DestinationSol/warp#3 by wrapping the SaveManager write methods with AccessController::doPrivileged. The save read methods have not been wrapped, since having modules re-load the current world might be considered too destructive.

Testing

• The API classes should now be accessible from modules. This can't be tested directly with the current line-up but after this change warp might start using the GameOptions class
• Use the ability of the Warp Endeavour ship and ensure that the crash in Warp Endeavour ability causes game crash DestinationSol/warp#3 does not occur.

Notes

ECS System classes have not been included as API classes, since I believe that the intention was for communication between systems to occur via components and events, rather than directly. I am open to changing this though.

[NicholasBatesNZ]

Had a look at why this one's red — good news, it's not really this PR's fault. The build fails at :engine:compileJava with 36 x cannot find symbol: class API because the @API annotation moved packages on develop since Feb 2022: it's now org.terasology.context.annotation.API rather than org.terasology.gestalt.module.sandbox.API (all 43 @API files currently on develop use the new path).

I merged this into current develop locally — no conflicts — and swapped that import in the 18 affected files, and both :engine:compileJava and :engine:compileTestJava go green with no other changes. Everything this PR wants to export still exists too; all 15 ECS component/event packages plus Const, GameOptions, SaveManager and RenderableElement are still there, so there's no deeper rot.

Seems a shame to leave it sitting — would you be up for refreshing it? Happy for someone else to pick it up otherwise. (Separately: the AccessController.doPrivileged bits now emit deprecated-for-removal warnings on the Java 17 baseline, but InjectionHelper and ModuleManager already do the same, so that's an engine-wide conversation rather than a blocker here.)