Housekeeping: deprecate, replace or remove archaic utilities classes.

[Moderocky]

Description

A lot of utility types were left over from Java 6.
Most of these weren't used at all, but a few are still being used in place of the proper equivalent in legacy code.
This pull request is a bulk group task to deprecate all of these for removal, and to replace internal uses of them all with a better thing.

Where possible, compatibility is perfectly preserved, but in some obscure cases (e.g. constructors) parameters have to be changed.

Legacy libraries

Some legacy libraries have been removed, moved, or just deprecated for removal.
Stubs for each one have been left behind (so technically nothing still using them will break).

Legacy functional interfaces

We have a legacy equivalent of Predicate, Consumer and Function, along with some others.

A lot of these can be replaced without any breaking changes. For some, where a method signature has changed, a plugin extending the method would need to be recompiled but wouldn't require any changes: for example, a method accepting Predicate<T> will also accept the deprecated Checker<T> because that is now a predicate itself.

The process is as follows:

1. Make the legacy class extend its proper replacement (e.g. Checker<T> extends Predicate<T>)
2. Forward a default method call from the proper method to the legacy method
3. Replace uses of the legacy class with the proper class (where possible)
4. Deprecate the legacy class and mark it for removal.

This is a branch merge request!

Individual pull requests were made by contributors to its feature branch: this can be merged as-is to preserve the Git change history.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: none

[APickledWalrus]

My primary concerns with these changes are that the Java-equivalent classes have methods for function composition. For any classes implementing these now deprecated classes, they now have these methods which may not be properly implemented (or work how one might expect)

[APickledWalrus]

The implementation of Predicate here raises some fun questions. It contains several default methods that allow you to modify the predicate. I'm not sure how applicable they are, but we might wish to override them or disallow them completely.

For example, should negate() function the same as setNegated(!isNegated())? It might be the case that negate() expects a new object rather than the same one (which we can't really promise)

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/function/Predicate.html

[Moderocky]

No walrus they don't modify the predicate they retain adjusted wrappers for it, e.g. the negation of o -> true would be (!(o -> true)).

[APickledWalrus]

I mean that the methods such as negate are a bit unexpected on PropertyCondtion, especially given we already have setNegated

[APickledWalrus]

Suggested change

	if (replace)
	Files.move(from.toPath(), to.toPath(), StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);
	else
	Files.move(from.toPath(), to.toPath(), StandardCopyOption.ATOMIC_MOVE);
	if (replace) {
	Files.move(from.toPath(), to.toPath(), StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);
	} else {
	Files.move(from.toPath(), to.toPath(), StandardCopyOption.ATOMIC_MOVE);
	}

[APickledWalrus]

are we able to override test for its parameter to be nullable?

[APickledWalrus]

Was there a reason to remove this class? It seems like there is now some duplicated code in the vector elements.

[Moderocky]

This is from @kiip1 's PR

[kiip1]

Although a few duplicate cases have been introduced by these changes, I still feel moving the static methods to where they're used is beneficial, besides the content of these methods won't ever change so the duplication of the methods doesn't matter as much.

Another argument for this change is that there are many more cases where it isn't duplicated, so you'd either be left with unused methods in VectorMath (in case you keep all methods) or a very minimal VectorMath (in case you remove the duplicate methods). I prefer removing the entire utility class over keeping a partial class or having unused code.

At the end of the day you do have a fair argument, and there are multiple ways to solve the problem and I chose the solution which removes the entire class, at the cost of some duplicates.