Add Translatable interface for fluid creation of TranslatableComponents

[2008Choco]

This PR adds a simple TranslationProvider interface to more fluidly create TranslatableComponent instances. While nothing in the Bungee API needs to implement TranslationProvider, the Spigot API can most certainly use this interface for types such as ItemType, BlockType, EntityType, Enchantment, so on and so forth.

While yes Bukkit does already have a Translatable interface, it cannot be used to directly construct a TranslatableComponent which makes working with it cumbersome and forcing developers to access the translation key rather than passing the translatable object directly. Bukkit's Translatable interface may extend BungeeChat's TranslationProvider interface for convenience.

// Before
TranslatableComponent component = new TranslatableComponent(Material.STONE.getTranslationKey());
// or
BaseComponent component = new ComponentBuilder()
    .append(new TranslatableComponent(Material.STONE.getTranslationKey()))
    .build();

// After
TranslatableComponent component = new TranslatableComponent(Material.STONE);
// or
BaseComponent component = new ComponentBuilder()
    .append(Material.STONE)
    .append(Material.STONE.asTranslatableComponent()) // Alternatively
    .append(Material.STONE.asTranslatableComponent("first arg", 2)) // Can be used to pass args as well
    .build();

Perhaps ComponentBuilder#append(TranslationProvider) is not clear enough, in which case I propose appendTranslatable() instead as a clearer distinction. I'm open to either one.

[Janmm14]

To not confuse users and due to the intended usage inside spigot, the Translateable interface in bungee should have a different name from the existing spigot one.

[2008Choco]

To not confuse users and due to the intended usage inside spigot, the Translateable interface in bungee should have a different name from the existing spigot one.

I disagree. I think there are plenty of examples of instances where BungeeChat has clashing names with Bukkit classes. ChatColor and some hover contents (Entity and Item) come to mind. The most common use case of this interface would be to pass instances into a TranslatableComponent or a ComponentBuilder. It would be rare for developers to specifically want a Translatable instance as a parameter, and if they do, I'm certain they should be competent enough to understand how to correctly declare packages to distinguish the two types.

If @md-5 agrees with you however, I would at least like to propose one of the following alternatives:

• TranslatableObject
• TranslationSource
• TranslationProvider

[Janmm14]

Item doesnt clash, ChatColor is due to pre-component-api

[md-5]

The Bungee clash causes big issues, but also ChatColor is used a lot more.

That being said, I probably like TranslationProvider the best

[2008Choco]

I have no issues with TranslationProvider (it was my preferred option as well). Updated and ready to go 👍