Remove ArrayUtilities and replace with Java built-ins

[concurrent-recursion]

Removed ArrayUtilities, ArrayUtilitiesTests, and replaced with built-in Java methods.

Resolves Issue 863

[Gamebuster19901]

I see the rationale behind cleaning up redundancy and relying more on java’s built-in features like streams. That said, I’d like to share a major concern I have with this... Removing these utility methods might improve conciseness in some areas but at the cost of reusability and maintainability.

For example, as @nightm4re94 stated in #863, something like Arrays.stream(arr).collect(Collectors.joining(separator)) is technically a one-liner,.. but if it’s used in multiple places, we’re effectively re-implementing the same logic over and over. A single utility method (like ArrayUtilities.join) gives you:

• A central place to evolve or fix behavior (e.g., null safety, trimming, edge case handling, etc),
• A clearer, intention revealing API at the call site, (It's not immediately clear what Arrays.stream(arr).collect(Collectors.joining(separator)) is doing. ArrayUtilities.join, however, is very clear.)
• Less repetition across the codebase.

I understand and support simplifying where appropriate, but I think think removing these helper methods would has the opposite effect.

Additionally, ArrayUtilities is public api, downstream components (games using the engine) may be relying on it directly. If it's going to be removed entirely, then it should probably be deprecated for removal first.

[concurrent-recursion]

I think the key issue is that these are so many places where a list or array of objects are being converted to a comma separated string and back. I would think it would strictly be for de/serailization of data.

[nightm4re94]

Thanks @Gamebuster19901 for chiming in - I think there are truths on both sides that we can build a compromise from:

• The convenience of collecting these utility methods in one place in an intention-revealing and testable fashion is indeed a big plus
• We've had a clear stance now for deprecations before the 1.0.0 version of the engine, which is that there shouldn't be any. Adoption of the engine is still ridiculously low and the required adjustments in case of breaking API changes usually pertain to a few lines per project. We still consider this BETA software and with our / my strongly limited capacity we can't afford to maintain legacy code just for the sake of it being there.
• This PR is a great way of showing where the ArrayUtilities are used: 14 files actually consume this API within the engine. The degree of necessity for the utility methods strongly varies from methods that are basically used in only one place to more prominent ones like join.
• When issuing the original ticket Clean up ArrayUtilities #863 I did not yet have the full overview of the extent of this change. Basically I saw overly complex code being used in only a few locations and room for improvement. The target picture was not entirely clear and in hindsight I can now say that removing ArrayUtilities entirely might have been too ambitious.
• Our goal is definitely not to implement a full set of universal utility methods for projects that use LITIENGINE. I would always advise implementing libraries like guava or Apache commons instead.
• I think an ideal solution would still retain the utility methods that are used frequently while:
  • simplifying their implementation following state of the art language features
  • removing highly specific utility methods that are used infrequently and / or rely on outdated API