Allow mannequins to inherit server teams

[roccodev]

This slightly changes the way mannequin names are handled:

• When spawning the second entity, the new name from the profile is now used to name the player info entry. This is nice because it allows registering the mannequin in scoreboard teams.
• Team registration is only performed when the second entity is spawned, this is because the mannequin's name can change in-between due to the above. Perhaps I could also add a way to disable this, because in some cases (I'd imagine on track/untrack) it may override the team set by the server/plugins?

This is outdated, see #1312 (comment)

• When the mannequin has no CustomName, its nametag is hidden (by setting the option in its team), which matches 1.21.9+ behavior. Technically in 1.21.9 this depends on CustomNameVisible (otherwise the name can display but only on hover), not sure whether I should change it to match that, because in 1.8 and 1.9 the name is either always displayed or always hidden.

I also wanted to remove them from tablist after spawning (for versions that don't have the Listed flag, primarily 1.8) to match the vanilla behavior. Unfortunately, this has to be handled by server implementations because the vanilla 1.8 client needs to render the player at least once to save its skin (amazing implementation), which means the player info remove packet has to be delayed slightly.

[kennytv]

Using the profile name was previously intentionally removed https://github.com/ViaVersion/ViaBackwards/pull/1166/changes#diff-9fc9ea9045c8479af18a6a229a32878c47ff24799d37cab9349449f94b172998L426

[roccodev]

Hmm, the PR that made that change didn't go into too much detail on the issue, I can only guess it's

that causes us to lose our cool player names

in which case I think it might be because the name wasn't added to the team correctly (in the PR changes, that's still using mannequinData.name() which wasn't set to the profile name, and I also think the player wasn't registered again to the team after the profile was ready, which this PR mitigates by only registering it then.

[roccodev]

Okay so I changed it up a bit:

• The fake mannequin team allows hiding the nametag on empty names, like in my original implementation.
• I removed the profile name thing, instead I focused on allowing mannequins to retain the scoreboard team set by the server when they are turned into players.

The second part works like this:

• UUID team entries are stored for the entire lifecycle they'd normally have in the client scoreboard (i.e. until they are removed by team packets)
• When a mannequin is spawned as a player, the server team is assigned instead of the fake one if possible.
• When the server tries to update the mannequin's team and the mannequin is currently tracked, it is rewritten to use the player name instead of the UUID, like players expect. If the server removes it from a team, the fake team from VB is assigned back.

Note that with server-provided teams we can no longer show the custom name, but because adding entities to scoreboard teams is usually quite rare, I'd say it's worth the compromise to let the server handle it.

Once again letting server control the team means the mannequin's name and glow color can be changed, or its nametag/invisibility status changed manually, for example.

[couleurm]

could this be used to e.g. replace a player disconnecting in a mini-game with a dummy player that can still be killed until he logs back on?

[roccodev]

If I understand correctly, that can already be done, and it would also probably be easier with my original implementation that allowed servers to control the profile name. What this change makes possible though is carrying over the player's team color and other properties to the fake player for older clients, if you set the mannequin's team on the server.