Chunk loading logic can make getTileEntity calls, and these can
be off of the main thread (i.e lighting). The TileEntity fixer
makes a getType call, which will block on chunk load. Thus a
deadlock can occur between a lighting thread and the server thread.
This is highly useful for profiling vanilla code, and in some cases plugin code. It is somewhat expensive, though, which is why it was initially disabled.
I chose to use a system property instead of a configuration setting because 1) the MethodProfiler is exclusive to CraftBukkit and not part of the general API (the timings system is the general API equivalent), and 2) using a static final boolean property _may_ allow the JITter to optimize out the methods when disabled (though I'm not sure of it).
There are several changes to fix cases where the profiler code was broken slightly by other craftbukkit changes. All of cases have been fixed, except for the block entity ticking one, due to the cost of the getSimpleName call. For that, a ticking entry is used instead, so that time spent actually ticking the block entities can be compared with time processing the list.
This (effectively) reverts 7dde6cc566.
World.addEntity(Entity entity) calls addEntity(entity, SpawnReason.DEFAULT), which contains the code that was originally in addEntity (and some event code).
However, WorldServer previously only had addEntity(Entity entity), so if addEntity(Entity entity, SpawnReason spawnreason) was called directly, the UUID check that's found in it (the call to 'i') is skipped. This happens, among other places, in ChunkRegionLoader.spawnEntity (which /summon uses).
I fixed this by making WorldServer override the SpawnReason version, rather than the regular version. This is safe to do because the World version calls the SpawnReason version - it's not necessary to do the same thing in WorldServer.
