Adding the colour formatting programmatically allows us to use the same text in contexts where we don't want colour

Not functional yet, but can be set on fields

The sub-category implementation is pretty clean, but for some reason the root level needed a whole separate filter, because hidden entries were being added back at the wrong index...

Implement disablement for lists and sub-categories

To allow for having multiple dependencies and non-boolean dependencies, lets store dependencies in the form of a class.

This allows any one entry to depend on multiple other entries. **All** dependencies must be met for the entry to be enabled.

A dependency can be set to "hide when disabled", if one of the unmet dependencies has this set, the entry is not shown at all.

A dependency can have multiple conditions defined, if **any** condition is met the dependency is satisfied.

Static dependency generator methods seem cleaner than having the user construct an object and then run setter methods on it.

Similar UX to using builders.

- Move dependency generators to the base `Dependency` class.
- Move all dependencies into the same package, to allow constructors to be package-private.
- Add javadoc to `Dependency`'s methods.

`SelectionDependency` allows entries to depend on a `SelectionListEntry` being set to a particular value.

Multiple condition values can also be set. If any are met the dependency is satisfied.

Sub-classes such as `EnumListEntry` are also supported.

Also, satisfied -> met.

Untested, but hopefully mostly ok... Need to setup an Autoconfig demo that can be run in-game...

TODO: Allow a single field to have multiple dependencies.

Config fields can be annotated with `@DependsOn()` which can have the following parameters set:

- `value` the i18n key of the field to be depended on
- `hiddenWhenNotMet` whether the dependency should cause the dependent entry to become completely hidden
- `conditions` an array of condition strings that will be parsed to the appropriate type and compared against the dependency's value.

A wrapper annotation which contains a list of `@DependsOn` annotations. ConfigScreenProvider iterates over each DependsOn and adds multiple dependencies.

Move most of the implementation into the abstract class `ConfigEntryDependency`

Instead of each config entry having a collection of dependencies, create a new special DependencyGroup that can contain multiple other dependencies.

`DependencyGroup` implements `Dependency`, so it can be nested if desired. However, the annotation equivalent (`@DependsOnGroup`) cannot be nested due to annotation design limitations.

In other words, Autoconfig can only have one group per field.

Conditions are effectively logical operators, allowing for more advanced dependencies. E.g. `ALL` requires all dependencies be met, while `ANY` only requires one-or-more.

`DependencyManager` is used to build and setup dependencies in Autoconfig.

It needs to keep track of all config entries created/transformed.

Made it so that GuiRegistryAccess can have a DependencyManager instance associated with it.

Changes were a mixture of debugging and cleanup of unrelated code.

`DynamicEntryListWidget.visibleChildren()` can return an unmodifiable List, if the list needs to be modified, `children()` can be used directly.

This means we can simply use a filtered stream to remove hidden entries, rather than creating a semi-transparent `AbstractList` implementation.

Initial basic autoconfig demo to test out the current implementation.

Noticed that the `ExampleConfig` doesn't have any translation strings, so it's more a code example than a full demo as things stand currently.

Also, noticed that `@TransitiveObject` having a dependency doesn't currently work as expected. Intended behaviour would probably to add the defined dependency to all children of the object.

Allow DependencyManager to register an "override" annotation, and use this to register each child entry with its parent's annotation.

Like other config entries, `TextListEntry` should render `DARK_GREY` when its dependencies are not met.

`GuiRegistry` often deals with a list of config entry GUIs when handling a specific field. E.g. when a `@PrefixText` is present, or when child GUIs are returned by providers/transformers such as `@TransitiveObject`.

Rather than relying on the i18n key defined in `GuiRegistry`'s handlers, lets ask each GUI what it thinks its key is.

Additionally, reworked how "dependency overrides" work; instead we introduce an "additional dependencies" concept.

Also, made i18n prefix optional. Currently, the only optional part is the root config's i18n key.

The i18n key is an internal detail of `DependencyManager`, so it makes more sense to register an additional dependency against a config entry rather than a i18n key.

Just take a single `Collection`, rather than also trying to handle the field's annotations.

The caller should simply add any field-annotations to the collection before calling.

Override `Object.equals()` and `Object.hashCode()` in `DependencyGroup` and `ConfigEntryDependency` to allow comparison between different `Dependency` instances.

Ensure distinct annotations are used to construct dependencies - more efficient than ensuring all constructed dependencies are distinct.

Ensure no matching dependency is present when adding "single" dependencies to the groups list.

An entry's field was being overwritten by parent fields as `DependencyManager.register()` got called multiple times.

Instead of keeping track of the field, we can simplify things be maintaining a list of dependency annotations that have been registered with the entry.

This also means we can get rid of the separate `additionalDependencies` map and just have a list of annotations in the main `EntryRecord`.

This greatly simplifies `buildDependencies()`

This fixes outer fields being unable to depend on children of their siblings.

Introduce a `Condition` class that can represent more complex conditions than simply `condition == value`. For example `NumberConditions` can check if `condition > value`.

Split `ConfigEntryDependency` into Simple+Complex variants:

- For `SimpleDependency`, the condition type is the same as the config entry type. E.g. `BooleanDependency`
- For `ComplexDependency`, the condition is a `Condition` object, which relates to the same type as the config entry.

We could completely remove the simple variant and instead introduce a `SimpleCondition` whose `check()` method is simply `condition.value == entry.value` if this is preferred?

Mostly playing with what the API would look like if all dependencies used "complex" `Condition`s, at least under the hood.

Introduced `withCondition()` and `withSimpleCondition()` to try and provide low-boilerplate methods of having multiple/complex conditions.

Fleshed out `Condition` a bit more, introduced `BooleanCondition` and `EnumCondition`.

Reduced `SelectionDependency` in scope to only support `Enum` selections as that helped maintain type-safety with the generics.

Since `SelectionDependency`'s scope was limited to just Enums, this is required.

It also improves type safety and simplifies the `@EnumHandler` provider code greatly. Since we've already checked `field.getType().isEnum()` in the predicate we can safely cast `field.getType()` to `Class<Enum<?>>`;

Removed the `APPROX` operator for now, couldn't come up with a simple way to implement it generically.

Defined the generic type requirement `T extends Number & Comparable<T>` for `NumberCondition` values, allowing us to safely rely on `Comparable.compareTo()` when checking the condition is met.

All boxed-type numbers can be compared against other instances of the same type using `compareTo()`, which suits us perfectly.

This means `fromString()` can build a `NumberCondition` for any of the basic number classes instead of always using `Double`.

Instead of filtering for `distinct()` annotations after the fact, it's better to store them in a `Set` to begin with.

Remove usage of generic `Annotation` class, instead have methods accept separate collections of `@DependsOn` and `@DependsOnGroup` annotations.

This removes a lot of runtime validations and allows us to use compile-time type checking instead.

Made the abstract dependency classes reference a new `ConfigEntry` interface which describes all the `AbstractConfigEntry` methods that dependencies care about.

This allows for dependencies to not depend on any one specific config entry class, but instead an interface describing a set of config entry classes. For example the new `NumberConfigEntry` interface.

`NumberConfigEntry` describes a `ConfigEntry` that uses a type extending `Number & Comparable`. It is implemented by both slider classes and also `AbstractNumberListEntry`.

`BooleanDependency` and `EnumDependency` can still depend directly on `BooleanListEntry` and `EnumListEntry` respectively, unless you'd rather also use interfaces here to create a layer of abstraction between config entries and their dependencies...

It is now possible to depend on other fields using a relative i18n reference.

By starting the reference with a `.`, the referencing field's parent key will be inserted as a prefix.

It's also possible to start a reference with multiple `.`s. For each `.`, one "generation" of parent is removed from the prefix, allowing you to reference "cousin" objects too.

Add the optional ability to use the actual boolean button text (usually "Yes" or "No") instead of "enabled"/"disabled.

I think dependencies are starting to get complex enough that a builder actually simplifies things.

Have less similar code in implementing classes. Not sure if I like having internal/public versions of the same method though...

Move most stuff into `impl`, group dependency and builder implementations so that dependency constructors can be package-private instead of deprecated.

The various `getTooltip`, `getShortDescription`, `getConditionText`, `Condition#getText()` methods can now be passed an "inverted" parameter.

If "inverted" is `true`, then the generated text should be logically inverted.

If child groups have matching condition/inversion then we can flatten them into the parent group's tooltip.

`BooleanDependencyBuilder` can handle missing conditions, they default to `true`.

Dependencies shouldn't need to know how dependent guis will behave when the dependency is met/unmet.

Instead, we can define an "enable if" and a "show if" dependency on each gui.

For autoconfig, we can handle that with separate annotations; `@EnableIf` and `@ShowIf` with corresponding `*Group` annotations.

In `DependencyManager` we can simply map the annotation to a `DependencyRecord` and use this instead of the old `@DependsOn` annotation.

In `FieldBuilder` we can split `withDependency()` into `setEnabledIf()` and `setShownIf()`.

Each condition class should handle its parsing. `DependencyManager` should simply call the class's `fromConditionString()` method.

We don't need to keep track of `baseI18n` in the record, since we can parse the relative i18n key during construction.

This should also reduce the chance of getting effectively-equal duplicates.

Keep them package-private and `@ApiStatus.Internal`

Condition requires that the depended-on entry matches another entry's current value

ComparatorDependency is a holdover from early in the design. It might be removed, or perhaps re-worked into a "fallback" dependency for unsupported types?

Still need to re-work tooltips to properly handle dynamic matcher conditions

Avoid copying arrays or over-allocating memory by using a linked list

Introduce builder methods in the Definition records to reduce code duplication.

Instead of returning an Optional and having the caller throw the exception, centralise the throw

Improve tooltip generation for groups and for dependencies with "dynamic" matcher conditions.

Allow tooltip generation to be disabled, in-case the user wishes to define their own tooltip/label text manually.

Allow the stream api to decide on an efficient way of building an array of lines instead of appending to a list manually and then converting to an array

Also apply the prefix when registering, instead of when building.

Rather than applying the prefix if a key doesn't start with it, apply the prefix only when a lookup fails.

This may be cheaper than doing string comparison. It also removes the edge-case where a prefix may need to be repeated in a poorly chosen i18n key.

Keep them separate from the various `GUI` annotations by introducing a `Dependency` class

But only for dynamic matchers (for now)

We don't want generic dependencies being built accidentally. They might be useful in some edge-cases, but type-specific dependencies are better.