Fix `RunScript` to use local `haxelib` paths.

[MAJigsaw77]

This pr makes it so it uses the working directory when searching for lime's path this mainly ensures that if theres a local lime installed, itll use the tools from that lime and not from the globally installed lime.

[player-03]

Haven't tested this, but the code looks fine.

[tobil4sk]

It seems like there are a lot of weird edge cases with how lime interacts with local .haxelib repositories, and it's starting to get a bit difficult to keep track of all the issues that have been fixed. To avoid regressions I think it might be worth looking into adding some basic tests to the lime repo that recreate some basic setups and ensure correct behaviour.

[tobil4sk]

Prior to #1873, Haxelib.workingDirectory was set prior to running Haxelib.getPath, so this patch solves a regression (though, it does not occur with 8.2.3 because run.n hasn't been rebuilt).

Here is how to reproduce the issue:

• set global haxelib repo to one without lime intsalled
• run haxelib newrepo to create a local haxelib repository
• install lime in the local repository with a dev path outside .haxelib's scope
• rebuild run.n
• run haxelib run lime test ...

[joshtynjala]

it does not occur with 8.2.3 because run.n hasn't been rebuilt

Oops! Looks like we've overlooked that for a while now. I just added commit 49d81a6cf5cb5f269faf720298e66135c3a6bb21 to have GitHub Actions build run.n.

[tobil4sk]

Oops! Looks like we've overlooked that for a while now. I just added commit https://github.com/openfl/lime/commit/49d81a6cf5cb5f269faf720298e66135c3a6bb21 to have GitHub Actions build run.n.

We also need a way to keep the run.n checked into git up to date, otherwise run.n in git and haxelib releases might not be in sync and that can also cause confusion (I couldn't reproduce the issue with git until I recompiled run.n).

[joshtynjala]

Ideally, run.n wouldn't be committed at all, and everyone who checked out the Lime repo would need to build it themselves like they need to rebuild the native binaries.

I don't think that there's a good way to keep run.n updated in the repo except to do it manually from time to time.

[player-03]

I feel like it should be possible to automate somehow. We're just looking for PRs that touch RunScript.hx without touching run.n.

[joshtynjala]

Checking for RunScript changes wouldn't catch hxp changes, but I guess if we caught RunScript changes, it might be easier to force a manual update using that as a mechanism.