disguise api

[yannicklamprecht]

relates to #10584

Adds a simple disguise api that also makes sure that invalid entity data, not belonging to the type that is faked, is filtered.
It also adds a server generator module to reduce maintenance of the entity data filter.

tldr; The API provides a way to disguise any entity as another or a player with having the possibility to interact with the entity like with any others. The big advantage is that you've the whole vanilla logic and Mob Goal and Pathfinding included without hassle.

Testing the changes can be done using the following snippet:
https://gist.github.com/yannicklamprecht/639acba127a54f5617e1281f099b7aff

TODO:

• Add JavaDoc
• remove test plugin code
• comment paper-server-generator
• figure out how to get teams working with real teams, client side ones worked in my fork Non issue just use the Entity#getName() instead of the Entity#getScoreboardEntryName()
• remove player profile if player disguise on ServerEntiry#removePairing(player) to avoid client disconnects when moving away and approaching again. see disguise api #10478 (comment)
• wait until dev/1.21 is merged into master
• When player is disguised as entity his attributes are propagated to the client, which isn't supported by certain entities
• When player is disguised as entity that has no ability to interact/build, the server should not propagate the players action to the rest of the players. Otherwise the other player gets kicked.
• When changing disguise while in visible range from e.g. Boat to a Living entity disguise, attributes will be sent again. -> on disguise change => auto hide and show entity to players.

Effective loc:

• 600 loc in patches
• 3k+ loc generated filter classe
• 400 loc generator code copied from api-generator
• 100 loc for generating the filter class.

[MiniDigger]

Hey @yannicklamprecht, since I see you rebasing this PR all the time: you really don't need to do that for this particular one.
While we do like this API in principle, it opened up a lot of discussion internally and we are not really sure yet on how we want to land it. We do have an idea on how it could look like post hard fork, but for now you don't need to waste time updating it, unless you need it for your own uses of course.
Thanks for sticking with us!

[yannicklamprecht]

Hey @yannicklamprecht, since I see you rebasing this PR all the time: you really don't need to do that for this particular one. While we do like this API in principle, it opened up a lot of discussion internally and we are not really sure yet on how we want to land it. We do have an idea on how it could look like post hard fork, but for now you don't need to waste time updating it, unless you need it for your own uses of course. Thanks for sticking with us!

1. It's a no brainer to update the pr.
2. I need the feature in my own fork and I'm to lazy to workaround the fact that code generation for forks isn't working that easy after a code gen change somewhere this year.

[yannicklamprecht]

Post hardfork MR: #11793