bug#70036: 30.0.50; Move file-truename to the C level

[Theodor Thornhill]

Hi, all!

During the last couple of weeks I've been studying Eglots performance
and have been noticing a couple of things that I find very
interesting. It seems like `file-truename` is in the hot path due to the
fact that every request to the lsp server has to create the source file
location, and in every response we have to parse the location the
relevant file. `file-truename` is used for this, and its performance
isn't really up to snuff for what it provides, afaict.

Below I've supplied some benchmarks and profile reports along with the
actual patch. Before we discuss the patch itself, I want to get some
answers to the following:

 - Is there a reason that this function should be supplied at the lisp
   level?
 - Does it have to be recursive? It seems to eat up a lot of stack, and
   the comments in the file suggest that has been an issue before.

Firstly, I'll show some benchmarks

```
;; Emacs 29 branch

(benchmark-run 10000
  (file-truename 
"~/Work/some/long/path/to/parse/that/is/very/deep/deep/deep/super/duper/deep/deep.el"))
;; (1.810892642 1 0.051070616)


;; With new C implementation

(benchmark-run 10000
  (file-truename 
"~/Work/some/long/path/to/parse/that/is/very/deep/deep/deep/super/duper/deep/deep.el"))
;; (0.018811035 0 0.0)
```

As you can see, the C implementation, though naive for now is two orders
of magnitude faster, and makes a noticeable difference when running an
lsp server in emacs.

As for the patch - it now relies on wordexp to resolve the paths, and I
believe there is no real feature parity with the old variant as for now,
but I haven't seen any issues thus far. If this approach is accepted I
will of course make sure we have feature parity, unless that isn't
wanted.

As for the profiles - it is very clear the performance is better with my
version, as it doesn't really show up in the profiles, but in the
current state `file-truename` seems to eat up around 10-20% of the total
samplings.

And lastly - I've noticed that `redisplay_internal (C function)` shows
up as a _huge_ chunk in emacs 30, but not in emacs 29. Is this a known
issue, or something to look out for? I could open a different bug report
for this if needed.

Below are the profiles and the patch. On my system I needed to `ln -s
lisp/loadup.el .` to make it compile. Not sure if that is due to
differences between old and new `file-truename`, or something else.

Thanks,

Theo

emacs-29-before-everything
Description: Binary data

emacs-30-before
Description: Binary data

emacs-30-new-file-truename
Description: Binary data

emacs-Q-30-after-everything
Description: Binary data

0001-Move-file-truename-to-the-C-level.patch
Description: Text Data