Wilderness teleport obelisk fixes

The goal of this MR is to make the obelisks never teleport the player to the same obelisk that they're teleporting from (authentic, but currently not always happening). I seem to have succeeded, but I'm making this a draft because I don't yet understand why, so my changes may be incorrect.

What have you done in this MR?

• Made the wilderness teleport obelisks roll the destination obelisk fairly. The original code rolled all obelisks (including self), and then made the self obelisk roll over to the next one in line if it had been picked. This is unfair (the n+1 obelisk now has double chances of being rolled), and I replaced it with code that properly removes the self obelisk before doing the roll.
• Fixed the seemingly incorrect code to preserve the player's offset from the obelisk center after teleport. I noticed that sometimes, the teleport was not going through (the code successfully rolled a different obelisk than self, according to println, but the teleport nonetheless left the player in the same spot). After replacing the incorrect distance calculations, the problem seems resolved - but why? I thought the sometimes-incorrect distance calculations were preventing the teleport from actually going through, but I don't see why that would be the case. Plus, the problem even happened when the player was standing in the center, in which case xDif and yDif should have had the same sign anyway, so the calculation would not have been incorrect. I need to think about this more, or I need help from someone more knowledgeable, which is why I am posting this publicly (at the risk of looking dumb!).
• Made the teleport capture a 3-by-3 bounding box of players, in accordance with the teleport animation. Previously, it was leaving out players standing in the corners. Added a helper function to the region manager to facilitate this.
• If the player is tbed, give the standard tb message rather than telling the user they are being teleported. - Reverted, because it caused issue #1461 (closed)

Are there any tricky things testers should keep an eye out for?

• No
• Yes, as follows:
• I have tested these changes thoroughly.
• This requires extra testing due to changes to architecture or other similarly risky changes.
• I used the Thanos Tool for any JSON edits where possible, and have attached screenshots of any changes.
• I acknowledge that this contribution will be released under the AGPL license.

*** NOTE: If Gitlab complains about pipelines stating that you need to "Validate your Gitlab account" there is no need to worry. You do not have to do this and it is only occurring because OUR pipeline tried to run on your fork. While it's preferred that you do validate your account, you can safely ignore/dismiss this message from Gitlab. ***