Improve default enchantment API

[bruberu]

What

This PR is intended to fix an issue with tools being applied default enchantments from other tool types, as well as to expand the API slightly in the process, by adding functionality for letting default enchantment levels increase as the material level increases. The first issue had been made apparent by other sword items taking on the butchery knife's looting III.

Implementation Details

There is probably a better way to implement the default enchantment level increase, as well as a better way to name it in the code.

Outcome

Fixes other GT swords having Looting III unnecessarily

Potential Compatibility Issues

The new method added to IGTToolDefinition will require any other implementations of it to error, and anything reliant on the current oddity of GT default enchantments will also break as a result of this PR.

[Tictim]

The whole ToolProperty class is unguarded against other modification factors, despite them using builder pattern for instantiation. Changing material stats mid gameplay aren't the best thing to allow so we should come up with some solution. Currently the setters are only being used in CT integration stuff, which I think there's a better approach than allowing modification absolutely everywhere.

For the default enchant growth API, I think approaches like this is better:

public ToolDefinitionBuilder defaultEnchantment(Enchantment e, int level){
  return defaultEnchantment(e, level, 0); // default to growth level of 0 per harvest level
}

public ToolDefinitionBuilder defaultEnchantment(Enchantment e, int baseLevel, int levelGrowth){
  this.defaultEnchantments.put(e, new EnchantmentLevel(baseLevel, levelGrowth)); // a new data type to hold base level and growth at the same place
}

Then the enchant level for items can be calculated like this.

// EnchantmentLevel.java
public int getLevel(int harvestLevel){
  return this.baseLevel + (this.levelGrowth*harvestLevel);
}

If we want to support partial growth rate (e.g. enchant level going up every 2 harvest levels), then maybe we could make base level and level growth as doubles. On the evaluation then we can calculate the level as usual, and ditch the decimal parts. But changing ToolDefinitionBuilder#defaultEnchantment argument to double is binary break, so we should make yet another method if we want to do this.

This change will require changing the return type of the IGTToolDefinition#getDefaultEnchantments, but I think it's a fair change because not factoring the growth level in is incorrect anyways.

I guess this API change can be also applied to ToolProperty#addEnchantmentForTools.