Normalizes CraftEntity#toString/getHandle

[Lulu13022002]

Instead of hardcoding the class name, fetch it dynamically and show more useful info to distinguish the instances

[lynxplay]

Generally looks good to me, however I am a bit split on what is then actually included in the toString().

The fact that 99% of entities now only expose their uuid is fine to me, I don't think toString() is a reliable
debugging source in the first place.
Noting that, I am confused why you chose to keep CraftHumanEntity's name in the toString impl?
It sticks out a bit given other entities lost their debug information (like horse variants or itemframe rotations).

[Machine-Maker]

Maybe can just use handle.getScoreboardName so we don't have to leave the toString implementation in CraftPlayer either.

[Doc94]

How hard its make more "dynamic" the getHandle for avoid declare that for every class? or is not related to the point of this PR?

[lynxplay]

Unrelated to this PR and effectively impossible unless we want to create CraftEntity<E extends nms.Entity> which seems like a lot

[Machine-Maker]

There are probably some entity types that should have extra stuff, like itemstack (the itemstack itself).

Do we want to just do that later, starting from this point?

[Lulu13022002]

I don't think so, i think the minimal info we show here, the better otherwise it's very arbitrary like before. The only reason i put the player name is because player is a special entity. But i'm fine following lynx advice and just show the uuid for all entities.

[electronicboy]

99% of the time I log some random object, it's because I want some level of information from the thing; I did ponder the idea of using kyori examinables type of setup here so that we can more cleanly control what ends up being dumped out, things like "is this entity valid still" is always nice to see;

[Owen1212055]

At which point however, that all seems like scope creep.

This looks good to me.