api: Add support for playing sound with an "emitter"

[kezz]

This is a simple PR that adds the concept of a sound "player". The interface for Sound.Player is intentionally empty, as the way the client/server identifies a sound player is with the entity ID, an implementation detail that some platforms may not wish to expose.

The general idea is that a native implementation will implement Sound.Player on their entity class, allowing it to be passed directly as an argument into the playSound method. For platforms, they could provide utility methods to convert their entity class to an implementation of the Sound.Player interface which provides an entity object, or some other form of identifier. This can then be used to convert to the platform specific way of sending the entity sound effect packet.

Alternatively, the Sound.Player could provide an integer ID, but this is just exposing what is essentially a magic number, not something as constant as, say, a UUID. I'm also not 100% sold on the Player part, I think it's potentially too confusing with the actual player. Perhaps something like Sound.Maker or Sound.EntitySource?

[kezz]

Just a thought: it's worth noting that whilst this does fix #315, it doesn't "fix" the subsequent problem of having a method to play sounds coming from the audience member (unless an implementation decides to use Audience#playSound(Sound) for that).

The issue arises from the fact that if you have a ForwardingAudience, you can't run code like forwardingAudience.playSound(sound, forwardingAudience) or something similar, you'd have to iterate through each member of the audience and play the sound to them directly. This isn't a terrible solution, as in most implementations you'd be able to do code like:

for (Player player : world.getPlayers()) {
    player.playSound(sound, player);
}

However, this does mean that there isn't a cross-platform way to signal you'd like a sound to be played from each member of the audience and it is a potential problem with Adventure that there isn't a way to indicate this. Firstly, I believe that it should be specified exactly what happens with the Audience#playSound(Sound) method to avoid confusion across implementations as to how the sound would be played. Additionally, a method that mimics Audience#playSound(Sound) could be created to allow playing sound using each audience member as the Emitter, perhaps, as was suggested in PaperMC/Paper#5472, an additional boolean parameter to specify if the sound should follow the receiver or not.

[kashike]

playSoundFromEmitter?

[kezz]

playSoundFromEmitter?

Yeah I suppose that could work - I think it does potentially confuse the idea of Emitter as opposed to the "receiver" of a sound.

[kezz]

Rebased and added further clarification to the Javadocs for the added method/interface.

[kezz]

Following on from zml's comment in #330 (comment), I have updated this PR to add Emitter#self() which, when passed into Audience#playSound(Sound, Emitter) should cause the sound to be played from the recipient of the sound.