VR Shooting Range targets initial implementation + vehicle deconstruction fixes

[Subsonic154]

Additions:

• Added targets to the VR Shooting Range zones; currently their spawn positons are not randomized, and infantry targets do not move (but their appearance/names/suits are randomized; excluding a few spots that exclusively spawn MAXes, and they perform their random emotes and look around randomly).
• Added configuration options to application.conf to disable the VR Shooting Range target spawns, and change the list of bot names.
• Added VR zone friendly-fire warning message (turns out it was actually a GenericAction value, not a ChatMessageType value).
• Added the unique fade-out effect for players entering or exiting VR zones.

Changes/Fixes:

• Disabled self-damage and server-side explosion damage against players in VR zones.
• Player loadout is now reset when both entering or exiting any VR zone.
• When the player selects the VR zone they are already in from the teleporter menu, they will now respawn at one of the zones spawns instead of nothing happening to match live behavior.
• Fixed not receiving Cavern equipment that is part of a saved loadout in VR zones.
• Fixed vehicles disappearing early with no VFX if shot or interacted with during the deconstruction process.

Backend:

• Implemented handling for the avatar_bot object class and it's derivative objects; this consists of an AvatarBot class/object that is a stripped down version of an Avatar with some Player logic mixed in, paired with an actor called AvatarBotActor that is a stripped down version of PlayerControl that just handles the bare minimum for their function as shooting range targets.
• Implemented handling for the TriggerBotAction packet; this packet sent from the server to clients is responsible for making the bot avatars perform a random emote. It has some unknown properties, but that's what it does in it's default configuration that packet captures from live always had it in.
• Zones now have an actor slot and Sector/BlockMap logic for handling NPC's; currently this is only used for the VR Shooting Range zone targets.
• The VR Shooting Range zones (tzshtr, tzshnc, tzshvs) now use their own GUID pools instead of the default one, their bot avatar targets are assigned to a unique pool called "bots".
• Rewrote the VR bypass conditions for Cavern equipment/vehicles to be cleaner.
• Vehicles now get unregistered after they are deconstructed, instead of when PrepareForDeletion is called, as this was causing ValidObjects to nuke the vehicle on the client early if interacted with during the deconstruction delay. When the process starts the vehicle is simultaneously locked and stripped of ownership to prevent potential issues caused by interaction attempts while deconstructing (log warnings will happen if the player reopens their vehicle menu during the delay and attempts to change permissions, but they are harmless).

[Subsonic154]

Critical issue was found that needs to be fixed before merging.

[Subsonic154]

Issue should be fixed now, re-opening.

[Dethdeath]

Looks good.
One minor thing is that motion alarm sensors can be placed in the VR shooting range and they are invulnerable. Only the owner can deconstruct them via the map.

[Subsonic154]

I'm not sure how I'd be able to block deployment of the motion sensor inside the shooting range building yet, would removing the friendly-fire invulnerability on deployables suffice?

[Dethdeath]

It would yeah.

[Subsonic154]

In that case, done. Can always come up with a proper solution for that later down the line, but for right now it doesn't matter much as long as there's a way to get rid of them.