Minor bugfixes in prep for 1.28.

BBP and RaG compatibility fix. Mod now should work with those mods fully, and most other basebuilding mods which don't radically deviate from vanilla's code.

Fixed potential nullpointer issue with using my modded raiding tool to raid modded item locks.

- Removed some accidentally left over debug experimental code.

- Fixed SyncComboLockPermissions server null pointer error and some bad "ref" usage
- Added a custom 4-dial lock which uses 3-dial texture (Zen_CombinationLock4)
- Unfortunately you can't mod vanilla lock textures, so at least this gives some visual variety if your server doesn't have 3-dials in the loot table

- Fixed RaG and EvenMoreDoors compatibility
- Made some minor improvements to efficiency etc in code
- Added detailed description of JSON config to mod folder

Just a quick note for other modders: RaG basebuilding and EvenMoreDoors do not call super.CloseFence() when overriding the vanilla Fence code, and when mods don't call their super for vanilla functions it breaks all kinds of things, such as my mod - very frustrating and requires all kinds of silly creative solutions to get the mod to work again. If you're a mod author and you're reading this - PLEASE CALL SUPER() in your mods unless you have a very very good reason not to! EvenMoreDoors is obfuscated so I can't even read the source code for that mod, so if this update doesn't fix compatibility for that mod I'm not even going to bother trying to fix it as I don't have time to guess solutions for an obfuscated mod that fails to follow basic good modding practices.

- Minor optimization/stability improvements

Fixed "Overriding function 'OnStartServer' but not marked as 'override'" error.

- Removed some redundant server print logs that were used for debug purposes and were spamming the script log

Fixed a bug with sharing codes with other players. The combination lock's saved lock code was shuffling to a random code on each server restart, which meant that only the owner who attached it or any guests who entered the code before the server restarted would retain access to the lock. Anyone who entered the original code after the restart would not be able to unlock the door as they were actually dealing with a new random code.

Unfortunately in order to be able to share locks with other players again, the lock needs to be removed first and then re-attached to gates/doors so that the new code is saved and no longer random.

I strongly suggest setting "OwnerCanRemoveLockWithoutCode": 1 in the JSON config so that players can remove their own locks without needing to know the code, at least temporarily until everyone resets their codes.

Sorry for the inconvenience, took me a while to figure out what was going on.