Issue description:

Tinkers' Construct makes calls to OreDictionary::getOres(String name) in various places to look up items matching an ore name. However, this method will always register the given ore name in the ore dictionary regardless of whether the caller intends on registering items under that name or not. This results in the ore dictionary receiving ore name entries that are empty, which causes issues such as phantamanta44/tinkers-evolution#8, where other mods check for the existence of an ore by the existence of the ore name.

I propose replacing any such calls to OreDictionary.getOres(name) with OreDictionary.getOres(name, false), which avoids the registration of ore names at lookup.

The offending sites are, in particular:

• TinkersConstruct/src/main/java/slimeknights/tconstruct/library/smeltery/OreCastingRecipe.java

  Line 28 in 23034cb

  this(OreDictionary.getOres(ore), cast, new FluidStack(fluid, amount), calcCooldownTime(fluid, amount), false, false);

• TinkersConstruct/src/main/java/slimeknights/tconstruct/library/smeltery/OreCastingRecipe.java

  Line 32 in 23034cb

  this(OreDictionary.getOres(ore), cast, fluid, time, consumesCast, switchOutputs);

• TinkersConstruct/src/main/java/slimeknights/tconstruct/tools/common/block/BlockToolTable.java

  Line 133 in e281b3a

  for(ItemStack stack : OreDictionary.getOres(oredict)) {

Related issue for Mantle: SlimeKnights/Mantle#141

Versions:

• Minecraft: 1.12.2
• Forge: 14.23.5.2847
• Mantle: 1.3.3.56
• Tinkers Construct: 2.13.0.184
• CodeChickenLib 3.2.3.358

The reason we did those was often to ensure the list was the same instance if the entry was actually used. In addition, tool tables only ever display things from a tag we know has entries, so that usage does not matter. Since 1.16 solved this anyways with tags and I don't feel like refactoring 1.12, closing as a non-issue. Other mods should not assume existence of the list means it has entries.