Make Tracking Skill closer to OSI

[kamronbatman]

Currently tracking uses the "RunUO" method which was constrained due to performance. We should make it work properly like OSI.
Requirements:

• Search up to 1 tile per skill point in all directions (100 tiles at 100% skill)
• Do not search beyond an area's bounds. Example: Dungeon levels are next to each other on the map, but tracking shouldn't "cross" the void.

Technical Implementation:
A new GetMobilesInRange flag should be added called useConcentricSearch. This flag should fork the behavior to a new ref struct enumerable/enumerator. This new enumerator should enumerate sectors from the center sector of the given coordinates, radiating outward.

Example, let's say the range is 100, resulting in a depth of up to 7 sectors in all directions.
Loop 1 -> sector at 0/0
Loop 2 -> sectors at -1/-1, -1/0, -1/+1, 0/-1, skip 0/0, 0/+1, +1/-1, +1/0, +1/+1
Loop 3 -> sectors at -2/-2, -2/-1, -2/0, -2/+1, -2/+2, -1/-2, skip the middle, then +1/+2, etc
etc..

Here is an iterative approach, but will need to be converted to a recursive approach. Hopefully we can make assumptions and don't have to use a BFS.

          int x;
          int y;
          var incr = 2;
          
          y = -incr;
          for (var i = -incr; i <= incr; i++)
          {
              x = i;
              Console.WriteLine("Coordinates: {0}/{1}", x, y);
          }
          
          // Sides are incr * 2 - 2
          for (var i = -incr - 1; i < incr; i++)
          {
              y = i;
              x = -incr;
              
              Console.WriteLine("Coordinates: {0}/{1}", x, y);
              x = incr;
              Console.WriteLine("Coordinates: {0}/{1}", x, y);
          }
          
          y = incr;
          for (var i = -incr; i <= incr; i++)
          {
              x = i;
              Console.WriteLine("Coordinates: {0}/{1}", x, y);
          }

The idea of this enumerator is that we can end our search early if we already have 12 mobs and our next distance is the next multiple of 16 tiles (sector size). This is because all mobs at the next sector depth will necessarily always be too far away to qualify as the closest.

[danielfcastro]

A recursive approach would consume more memory. Why using it them?

[kamronbatman]

This method should consume no extra memory since we already have a ref struct enumerator. Just requires an algorithm that spirals, or scans left to right inside-out.