Refactor: LegacyApplication optimization + javadoc

[capdevon]

This PR introduces getter and setter methods for the paused state in the LegacyApplication class. This allows external control and querying of the application's paused status, enhancing flexibility for game state management.

Code Refinements: Minor optimizations and robustness improvements have been implemented.

Enhancing the Javadoc documentation across the entire class.

Add helper methods:

• initializeInputDevice()
• destroyInputDevice()

[yaRnMcDonuts]

I'm inclined to approve this;

However, I am wondering if there would actually be much use case for calling this setPause(true) method on the whole app, since it looks like this internal "pause" variable was originally meant to only be used for pausing the entire app when setPauseOnLostFocus() is set true. I think this is more of an internal pause variable specifically for freeing up resources and pausing absolutely everything when the game is minimized, and I don't know if there would be any actual way to set it back to false manually. Because if setting this true does indeed pause absolutely everything (including input) then there would be no possible way for the app to listen for input to change it back to false.

I like the idea of having a publicly accessible boolean for pausing the update loop, but if this pause variable also pauses menus and input, then I think a different separate pause variable should be added to pause just the update loop, and that way it isn't also being tied in with the setPauseOnLostFocus() functionality that also toggles the pause variable internally when the app is minimized and refocused. This would mean that a user who set pause true manually wouldn't be able to minimize and refocus or it would automatically unpause. So I think a new public pauseUpdateLoop variable would be the best way to do this, so that way it is entirely separated from setPauseOnLostFocus()

[capdevon]

Hi @yaRnMcDonuts ,
You're right. I usually set the LegacyApplication.speed to almost zero to pause the game. This way, all the moving objects, animations, and physics are almost motionless while the InputManager continues to receive input. I assumed that I could use the pause variable in the same way. However, as you pointed out, this approach does not work. Since using the speed variable is very subjective and may not suit everyone, it's best to remove the isPaused() and setPaused() methods. That way, programmers can decide the best way to pause the scene for debugging purposes. I am modifying the title of the PR so that this change deals almost exclusively with Javadoc, rather than adding new functionality.

Thanks for the feedback