🔨 Spatial partitioning of entities / octree implementation

[Zach Toogood]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

Describe the feature

Currently, we don't really have a proper broad-phase culling phase for looking up "entities near me" or "entities near this point". We either go through the whole entity lists in a zone for mobs/npcs/players etc. or we piggyback on the spawnLists we generate for players - which are built exhaustively I think.

This is fairly easily solved by using linear spatial partitioning, or something like an octree.

// Concept to ensure the class has position methods (CBaseEntity)
template<typename T>
concept HasPositionMethods = requires(T a)
{
    { a.GetXPos() } -> std::convertible_to<float>;
    { a.GetYPos() } -> std::convertible_to<float>;
    { a.GetZPos() } -> std::convertible_to<float>;
};

template<typename TFloatType>
class OctreeNode
children, bounds, payload(s), etc.

template<typename TFloatType = float>
class EntityOctree
{
public:
    template<typename T>
    requires HasPositionMethods<T>
    void insert(T* entity)

    template<typename T>
    requires HasPositionMethods<T>
    std::vector<T*> getNearby(T* entity, TFloatType distance)

Then it's up to the implementer to MEASURE and find out if it makes more sense to rebuild the octree at the start of every tick, or if it should live longer and have entities added and removed from it and then rebalanced. It's important that the octree either never holds pointers to entities that might be gone, or it is able to check and remove them from itself.