Policy: 'Any-X' type acceptor for common property patterns.

[Moderocky]

The Issue

A lot of property names are common between types. If one thing registers a property (e.g. size of %inventory%, it conflicts with everything else wanting to register the same property (e.g. size of %discord server%).

Names: The Worst Case Scenario

Lots of things have a name.

The list is currently offlineplayers/entities/blocks/itemtypes/inventories/slots/worlds and it's about to be joined by scripts and functions (and maybe a few other things too).
This isn't a problem by itself.

Unfortunately, this is not an exhaustive list of things in the universe that have names 😬
Addons like to register a name property for things that have names (such as discord users, channels, files, protocols, who knows what else) and they can, but Skript can't decide which syntax to pick when a user inputs a variable.

Is name of {_foo} asking for the name of a player/entity/block/.../world? Or the name of a discord user/file/.../tv show? We don't know, and we can never make the type-hint system comprehensive enough to tell.

What's the Ideal Solution?

We had a little attempt at fixing this a few months ago, by identifying cases where multiple patterns effectively matched and then creating a 'combined' syntax for that which selected one at runtime based on the inputs.
Ideally, it would be a dynamic bootstrap but that wouldn't really work in Skript's style, so it would probably have to select a syntax each time it was run.

Unfortunately, this was completely impossible because a lot of syntax are designed with the idea that something else will be matched first, and so we can't init them safely in any way, so we had to scrap the idea (at least for now).

A Solution

For these common properties, we could register an any-x type.
This would be a really simple functional interface supplying the expected return type, e.g.

interface AnyNamed { String name(); }
interface AnySized { Number size(); }

We can register this with Skript as a classinfo and accept it in the pattern.

Then, anybody wanting to provide name of X support for their own type can either:

1. Make the type implement AnyNamed (to provide native support)
2. Register a converter for their type to an AnyNamed using the functional interface