Checking the cache on member removal here isn't reliable due to race
with cross zone message
If a zone removes a member at the same time as another zone, neither zone
can know if the expedition will be empty via cache unless it processes the
world message from the other zone's member removal first.
Add DynamicZone sql table schema
Add DynamicZones logging category
Modify CreateExpedition to take DynamicZone and ExpeditionRequest objects
Implement DynamicZone compass, safereturn, and zone-in coordinates.
Implement live-like DynamicZone instance kick timer for removed members
Implement updating multiple client compasses (supports existing quest compass)
fix: Send client compass update after entering zones to clear existing compass
Implement Client::MovePCDynamicZone to invoke DynamicZoneSwitchListWnd
when entering a zone where client has multiple dynamic zones assigned
Implement OP_DzChooseZoneReply handling
Add Lua api methods for expedition's associated dynamic zone
Add #dz list gm command to list current DynamicZone instances from database
Add Expeditions logging category
Add handlers for all Dynamic Zone/Expedition related opcodes
Add FormatName string_util function to format character names
Add Zone::IsZone helper method
Add cross zone MessageString support with variable parameters
Add static Client method helpers for cross zone messaging
Add #dz gm command to debug expedition cache for current zone