Static instances removal

[czyzby]

• [x] I18n bundle - with idiomatic Kotlin NLS enums (see README file), the static nls methods are not as useful.
• [x] Dependency injection context - after full context initiation, context should not be accessed directly. Dynamically created instances should be accessible through injected providers.
• [x] Asset manager - with dependency injection from ktx-inject, static access to resources can be harmful and hide code dependencies. Fully loaded assets should be passed directly to the objects and functions that depend on them.

---

• [x] Add deprecation warnings to the mentioned instances and functions that rely on them.
• [x] Provide alternative utility methods for AssetManager usage, allowing the users to migrate to the new API before the next release.
• [x] Rewrite ktx-i18n documentation.
• [x] Rewrite ktx-inject documentation.

---

Most static variables are pretty much justified and optional to use. For example, you can still benefit from gdx-assets utilities without the global AssetManager, but most applications will want to use only a single one anyway.

I don't think the global Skin variable should be removed from ktx-scene2d though, as it greatly simplifies and improves readability of UI building methods.

@kotcrab @sreich @MrPlow442 I'd love to hear your thoughts on this.

[MrPlow442]

I believe I might be the least qualified here to suggest anything but here goes. I come primarily from web development where globals are frowned upon and are mostly replaced by singletons managed by DI frameworks. With that mindset I'd suggest to forgo globals where possible and let users decide where, how and when to instantiate and use these utilities. Is there any significant difference if you offer a global AssetManager or if you register it in ktx-inject or kodein or any other DI framework as a singleton? In both cases it should be equally trivial to reach the instance, with the DI giving additional benefits in TDD. I haven't yet used scene2d extensions so I'm afraid I cannot comment on that.

[czyzby]

@MrPlow442 That's basically my background and mindset, really. I originally transfered some of my personal Kotlin utilities without giving it much thought and I believe keeping the globals around was a mistake. I think deprecating all static instances (and utility functions that depend on them) makes sense, I'll eventually remove them in a future release.

[kotcrab]

I agree with removing static instances of I18N bundle and assets manager. Those can be handled better.

What about deprecating static context for ktx-inject, this would require passing context instance to every class that wants to use DI, right?

Scene2d.ui Skin makes me sad that it's not handled by the Stage itself, I think it's just better to keep it static here.

[czyzby]

What about deprecating static context for ktx-inject, this would require passing context instance to every class that wants to use DI, right?

This would require you to design your classes in such a way that you don't need it - injecting only the providers that you plan on using dynamically.

Scene2d.ui Skin makes me sad that it's not handled by the Stage itself, I think it's just better to keep it static here.

Agreed. Having to pass skin variable to every UI building methods would clutter the API and would be inconsistent with VisUI which provides Skin instance internally.