Add wayfinding and related rendering options

[ETcodehome]

What issue does this PR address?

While playing tileman mode with auto mark on, a frequent source of frustration is that the player can't reliably move along an already claimed path without accidentally claiming a new tile. Additionally, the cost in tiles to move to where you've currently selected is not clear before starting to claim a path.

---

How does it address the issue

This PR:

• Adds a Dijikstra based path generation implementation to the plugin so that the path to current cursor location can be generated and rendered. This implementation uses the collision data exposed via the RuneLite API for loaded regions around the player. The path generated matches the path that RuneLite will take to the cursor position.
• Adds customization options to the TilemanMode config menu around how each component of the new wayfinding overlay renders.
• Updates the config and overlay menus with the relevant information relating to the new feature including optionally exposing related performance metrics in the info overlay.

Feature screenshots (varying example configurations)

New config menu settings:

Walking a claimed path (claim tiles set to inset)

Walking an unclaimed path (example custom configuration)

---

Testing performed

• Been playing while developing it for most of a week resolving small edge cases as they were found
• Provided numerous high complexity test cases involving path logic around obstacles always resulting in 1:1 wayfinding with the actual run path taken.
• Tested multiple planes / world locations
• Found functional implementation limits (explained in edge cases below)
• Multiple feedback rounds with active tilemen to discuss sensible default configuration for the new wayfinder feature.
• Interacts superbly with new group tileman functionality

---

Edge case handling explanations

The wayfinding rendering is disabled when shift is held

This is done to make it easier to right click and claim / unclaim tiles without the new wayfinder overlay interfering.

Sometimes I can't wayfind very far in front of me

This is to do with how RuneLite / RuneScape loads regions. Most users of RuneLite run the gpu plugin that loads additional visual only chunks around the player. These additional chunks don't report data correctly for many of the underlying API methods that rely on the region to be loaded. This load distance can also be really bad, visible if you reduce the extra chunks loaded setting in the gpu plugin:

There's not really a pragmatic / practical solution for this, and 99.9% of the time it's not a problem when using the wayfinder, and most the time this distance is inside the 32 tile max rendering distance that is already in place for claimed tile rendering.

Paths to an interactable object don't show

This is by design. The wayfinder will only map paths to clear tiles not left click interactables. I spent considerable time investigating this including speaking with the lads in the RuneLite dev channel. Essentially when a player clicks on an interactable that is multiple tiles wide or has a specific interact direction, the player pathfinds to the closest point then attempts an interact. The server then sends back a scripted movement instruction, to move to x tile so you can interact with it. This data isn't available ahead of time, and other plugins such as shortestpath have to statically map these positions to fix this issue (ongoing maintenance headache).

---

Risk Analysis

Annoying existing plugin users

Primary concern is that by making changes to menus / features that players are using in a certain way they might get annoyed (people hate change, even worthwhile ones).

Mitigated almost entirely by ensuring the new wayfinder functionality can be one click toggled off using a single checkbox leaving the existing rendering behavior functionally 1:1 with the existing.

Performance implications of path rendering

Mitigated by #49 and #50 leaving us heaps of overhead to play with.
Mitigated by only recalculating when the player changes location or the target tile changes (one calc per tile target).
Mitigated by efficient proven wayfinding code implementation.
Mitigated by exposing live performance data showing path calculation costs as <1ms (min java time precision) on my hardware.
Mitigated by wide variety of test cases during development
Mitigated by efficient search limitations
Mitigated by utilising RuneLite core implementations for collision data

[ETcodehome]

@ConorLeckey @sram1337
I think this one is probably (overdue) ready for a look when you have a chance.

I've been running this in parallel with all the other work we've been doing because I found the wayfinding QoL and diagnostics so useful along the way, so it's been kept in good order as other changes have progressed. The screenshots above are a little outdated as things like group tile config options were also added.

I think it'd be good to get this one merged to avoid conflicts with any sailing fix as there is (admittedly) a bit of complexity in this change set that could potentially lead to conflicts.

Once this is merged I'll start looking at addressing sailing issues.