A version two?

[i509VCB]

Static data surprisingly still works on the latest version of fabric loader (0.9.0). Aside from that there are a few things static data does not cover well, and I have rewritten to in the end be more flexible.

This is sadly not backwards compatible.

Changes:

• Addition of DataSource, an abstraction of the "source" of a static data item. A data source is either the "global" or from a mod (mod container).
• All static data methods which used to return an ImmutableSet now just return Set<StaticData.Item>. The returned set is still unmodifiable (using Collections).
• StaticDataItem is now a subclass of StaticData. StaticDataItem -> StaticData.Item
• StaticData.Item is now an interface.
• StaticData class is now final
• Bump loom
• Add testmod sourceset for some testing.

This is a draft PR since I will be writing a couple of tests first using the testmod source set.

Also I am going to hook up licenser and clean up the buildscript.

[falkreon]

I feel like DataSource is either undesirable or misnamed.

A "data source" as stated is a String corresponding to a mod resource domain, or in the case of the server staticdata folder, "g" or "global".

Then there's a useful concept of "data providers", there being a distinct queryable list of objects that correspond to a particular resource-domain but can be individually queried for more data - probably as the result of information from a previous query.

I feel like the class suggests the latter but the name suggests the former.

I'd caution against forcing Identifiers used by the static-data system to take the same form as Mojang's resource system. You cannot necessarily ask Mojang's resource system to provide you with the data from that Identifier and get the same data, or any data at all. The "resource-domain" of a static-data identifier must correspond to the data-provider in question, otherwise there is literally no way to go back to that domain to look up additional/related data. Basically, the ability to lie undermines the whole system.