Core/Misc: Add a validity check for coordinates, prevents crashes
Core/Movement: Fix random position finding near edges, avoid big z-coordinate differences
Core/Units: Fix issues with threat management on phase changes
DB/Creature Template: Some updates, mostly HoverHeight and InhabitType. Thanks to KingPin for re-parsing ~5GB of sniffs.
Core/DBLayer: Convert PAppend() queries to prepared statements No.4 NOTE:

Most of the cores queries have been converted to prepared statements now. If your code contains queries, please either use the exiting or implement new statements.
The only exclusions are one-time queries (e.g. for core startup) and queries that can't be prepared due to limitations.
Core/Spells: Fix Misdirection (thx to elron) closes #5869, #4343
Core/Spells: Fix Necrotic Touch proc closes #538
Core/Spells: Added sql for misdirection fix (thx dasio)
Core/Spells: one more miss from misdirection fix
Core/DBLayer: Restore pet loading

closes #5878
Core/DBLayer: Typo from prev. commit
DB/Auth: Update auth_database.sql with recent changes
Core/Spells: and another mistake from the misdirection fix >.>
Core/DBLayer: Fix `creature` and `spell_rank` loading
Core/DBLayer: Correct few more wrong read types (No. 1)

DB/World: Some consistency in the ints "length" field (not really a length)

From A to D world tables verified; missing all the others

int(11) -> int32
unsigned int(10) -> uint32
mediumint(8) -> int32
unsigned mediumint(8) -> uint32
smallint(6) -> int16
unsigned smallint(5) -> uint16
tinyint(4) -> int8
unsigned tinyint(3) -> uint8
Core: Remove the MersenneTwiser-library (SFMT is now considered stable enough for full deployment)
Core/Groups: Remove redundant check in WorldSession::HandleLootRoll
Core/DB Layer: - Fix "Thread #1 unlocked a not-locked lock at 0x6D56E90" helgrind error (thanks to Aokromes for logs). Cause was unlocking MySQL connection on shutdown, but concurrent access at this point is not required.

- Remove redundant locking in PingOperation. Since these are delayed to async threads with their own MySQL connection, no concurrent access here either.
- Codestyle cleanup
- Documentation refining
Core/DB Layer: Fix helgrind errors on some concurrent access to resultset auto pointers.
Example:
==8753== Possible data race during read of size 8 at 0x2e803e60 by thread #8
==8753==    at 0xDD0FFC: PreparedResultSet::operator[](unsigned int) const (QueryResult.h:83)
==8753==    by 0x131D82D: WorldSession::HandleCharEnum(Trinity::AutoPtr<PreparedResultSet, ACE_Null_Mutex>) (CharacterHandler.cpp:217)
==8753==    by 0x118F8C3: WorldSession::ProcessQueryCallbacks() (WorldSession.cpp:1087)
{..}
==8753==  Address 0x2e803e60 is 0 bytes inside a block of size 16 alloc'd
==8753==    at 0x4C28B75: operator new(unsigned long) (vg_replace_malloc.c:261)
==8753==    by 0x137D515: __gnu_cxx::new_allocator<Field*>::allocate(unsigned long, void const*) (new_allocator.h:92)
==8753==    by 0x137D378: std::_Vector_base<Field*, std::allocator<Field*> >::_M_allocate(unsigned long) (in /home/aokromes/bin/bin/worldserver)
==8753==    by 0x137CEC6: std::vector<Field*, std::allocator<Field*> >::_M_fill_insert(__gnu_cxx::__normal_iterator<Field**, std::vector<Field*, std::allocator<Field*> > >, unsigned long, Field* const&) (vector.tcc:416)
==8753==    by 0x137CB27: std::vector<Field*, std::allocator<Field*> >::insert(__gnu_cxx::__normal_iterator<Field**, std::vector<Field*, std::allocator<Field*> > >, unsigned long, Field* const&) (stl_vector.h:944)
==8753==    by 0x137C964: std::vector<Field*, std::allocator<Field*> >::resize(unsigned long, Field*) (stl_vector.h:632)
==8753==    by 0x137BFCA: PreparedResultSet::PreparedResultSet(st_mysql_stmt*, st_mysql_res*, unsigned long, unsigned int) (QueryResult.cpp:98)
==8753==    by 0x137A12B: MySQLConnection::Query(PreparedStatement*) (MySQLConnection.cpp:493)
==8753==    by 0x137F663: PreparedStatementTask::Execute() (PreparedStatement.cpp:412)

Have a feeling this is a false positive, though. Nevertheless good to get rid of.
Core/Misc: Make World::m_stopEvent thread-safe. Note that the 'virtual' keyword in C/C++ is pretty useless for multithreading