HLS can't execute build-tools if they are defined in the project's own cabal file

### Your environment

Which OS do you use?
NixOS
Which version of GHC do you use and how did you install it?
9.0.2 from nixpkgs
How is your project built (alternative: link to the project)?
Cabal/cabal-install in a nixpkgs/direnv-provided environment

Which LSP client (editor/plugin) do you use?
Emacs, VSCode
Which version of HLS do you use and how did you install it?
1.7.0.0 from nixpkgs
Have you configured HLS in any way (especially: a `hie.yaml` file)?

```nix
cradle:
cabal:
- path: "src"
component: "lib:demo"

- path: "./Main.hs"
component: "demo:exe:demo"

- path: "./Paths_demo.hs"
component: "demo:exe:demo"

- path: "test"
component: "demo:test:spec"

- path: "./vendor/github.com/xyz/haskell-lib/prelude"
component: "lib:xyz"
```

Edit: The entry for our equivalent of `my-tool` below is missing here, but adding it makes no difference to the behavior observed.

### Steps to reproduce

If you have a project that defines a

* a `executable my-tool`
* a library that has `build-tool-depends: my-project:my-tool`

and the latter contains a file like this:

```hs
{-# OPTIONS_GHC -F -pgmF my-tool #-}

-- any further code
```
HLS will show an error on that file saying it can't execute `my-tool`.

### Expected behaviour

HLS should (in my opinion) do one of the two things:

* Recognize that the executable is declared properly as a `build-tool` and present in the same cabal package, but can't be executed because it would not be available in `PATH` automatically / prior to building it. Instead of an error, it should display a warning informing about the situation.
* Execute the preprocessor from `dist`/`dist-newstlye` as Cabal would. This is of course tricky, because it'd mean that HLS needs to build this executable without an explicit request from the user to avoid using an outdated version of the preprocessor.

### Actual behaviour

HLS will show an error on that file saying it can't execute `my-tool`.