bug#34107: Kdenlive searched-for paths

[pkill9]

There are a few issues with Kdenlive I've found, mostly relating to finding 
paths for things:

It doesn't know where to look for mlt profiles by default, so it asks the user 
in a popup where to look for them - the default suggestion in the popup is 
incorrect (constructed like '<guix-profile>/bin/share/mlt/profiles). The 
correct path is found with `$(guix build mlt)/share/mlt/profiles`.

It stores this path in the '[env]' section of ~/.config/kdenliverc, which it 
autogenerates. If it doesn't find the mlt profiles in this stored path when 
run, it asks the user to specify the path in the popup again.

It also stores other paths it needs that it finds, like the path to ffmpeg (to 
the relative guix profiles they're in, e.g. /run/current-system/profile and 
~/.guix-profile. I don't know if this is an issue, I think it will just try to 
find these other paths again if they're invalid when starting kdenlive.

One way to fix the mlt path not being found is by wrapping the kdenlive 
executable with an additional CLI flag `--mlt-path 
<path-to-mlt>/share/mlt/profiles`. It would maybe better to use an environment 
variable (which could either be wrapped, or if propagated could allow 
additional mlt profiles to be added to the guix profile) but I couldn't find 
one for specifying the path to the mlt profiles.

-----

Another issue is that it heavily uses the icons from the breeze-icons package 
(which it gives a warning if not found), and these need to be installed to the 
user's profile (not tested with system profile) as kdenlive doesn't find them 
when running `guix environment --ad-hoc kdenlive breeze-icons -- kdenlive`

It also gives the warning
```
No LADSPA plugins were found!

Check your LADSPA_PATH environment variable.
```
which is gotten rid of by running kdenlive with `LADSPA_PATH=$(guix build 
ladspa)/lib/ladspa kdenlive`. This environment variable could also be added to 
the kdenlive wrapper, and/or added as a search path.