Don't install crest to xtb's folder, create a separate bin directory

[matterhorn103]

Currently, the plugin looks for xtb and crest in the following places (where avo_xtb is the plugin's root directory):

xtb:

• avo_xtb/xtb/bin/xtb (or xtb.exe on Windows)
• the system PATH via which xtb

crest:

• avo_xtb/crest (an .exe isn't checked for here)
• avo_xtb/xtb/bin/crest
• avo_xtb/xtb/bin/crest.exe
• the system PATH, again via which crest

This reflects the fact that the plugin-managed automatic installation of xtb and crest puts first the xtb program directory into avo_xtb and then crest into avo_xtb/bin/, next to the xtb binary.

Since crest is a separate program, this is not really ok, and it prevents updating the two programs separately, and if crest one day switches to a structure similar to xtb, it won't be tenable.

Instead, there should always be an empty directory bin within avo_xtb, and automatic installation should put crest there. The first place checked for both binaries, and for obabel, should then be avo_xtb/bin/.

This will allow users to manually put symlinks here to binaries located in other places, if desired.

It also seems to be possible to create soft links with pathlib on all platforms. Whether this requires elevated permissions needs to be investigated. If not, it makes sense to automatically setup a link to the xtb binary from this folder.

Potentially, the plugin could also automatically link from this folder to any path provided manually by the user i.e. the targets of avo_xtb/bin/xtb, avo_xtb/bin/crest, and avo_xtb/bin/obabel could be updated to the values in the config (config["xtb_bin"] ... etc.) whenever they change.

The main disadvantage of this that I can see is that it might not be sufficient to check for avo_xtb/bin/xtb, it might be necessary to confirm that it's not a dead link.

Finally, since xtb and crest are not part of Avogadro, it could be considered more appropriate to store them in the top level of the user-installed program directory (i.e. XDG_DATA_HOME on Linux, which is ~/.local/share by default) and then link to those binaries. In this way, avo_xtb is essentially carrying out a user-wide installation on behalf of the user. However, this requires the plugin to have permission to install there, which may not be the case, especially if the app is sandboxed/flatpaked, though a permission check might suffice. This would also require platformdirs as a dependency to determine the correct locations, which is considered in #20.

• Create a bin directory in the plugin directory
• Change the installation location of crest to the bin directory when installing crest automatically
• Create a symlink to avo_xtb/xtb/bin/xtb in the bin directory when installing xtb automatically
• Likely: Create and update symlinks to the different binaries in bin based on user choices in the UI
• Unlikely: Install xtb and crest outside of the plugin's directory when installing automatically