The name was a relict from the very first day of project structuring,
but this name here makes for much much nicer tab-completing to source
file names...

And minor cleanup

When opening context help the topic can now be anywhere on the page.
Also: QTabWidget::clear() clears the tabs but does not delete
anything... oops. Now we do this manually potentially saving big amounts
of memory and lookups.

A bug has been found where the user manually edits the run path in a workflow and makes it invalid...

The problem is that the command that should run does not run and we show
an error message saying that the command could not be found when it fact
it was an invalid run path... A hacky way of catching this kind of
errors has been implemented, but it wold be better to be able to show an
error message in the log window instead of only in the status bar.

Cf. https://models.slf.ch/p/inishell-ng/issues/857/

Ideally, it should onyl be printed the first time a command is executed
(this is useful for users who have multiple versions of a binary as it
is the only way to have a chance to figure out which one will be
called). Otherwise, minor constifications in main.cc

After hours of fighting, I managed to implement a workaround. The
problem is that when creating an ini file from scratch (for example for
MeteoIO) and running it directly (after saving it to a file), the
workflow output path can not be read (${key:OUTPUT::METEOPATH} can never
be read, it is actually empty). This comes from the fact that
MainWindow.getINI() does not contain the same keys as in the INIParser
just after saving... So the dirty fix is to copy this content to
MainWindow.ini_ just after saving so the WorkFlow object has access to
the user provided configuration. Hopefully, a clean fix can be developed
at some point.

Noteworthy: Removed fixed shortcut in doc because it is OS-dependent.

As well as a minot tweak in the project file

Unfortunately, the Snowpack provided examples require to run on level higher than the config files. This is now possible but made me realize that relative paths should not be expanded against the path of the ini file but against the current working directory (the other convention makes sense for include files but not for the inputs/outputs)

(Because the rest of INIshell is very clean concerning OS-specific code, so it's nice to collect it)

Properly implement and document the newish workflow checkbox so it can be called by ID as the others. Minor cleanup in recent features; typos.

I did not see it being used anywhere, so if it is, please check if
something broke.

A missing icon (on Mac) has also been added

Some obsolete calls for Mac have also been removed.

Do mini TODO: start showing a hidden Number when the minus sign is entered. It's not perfect but better.

Properly implement yesterday's 'buildall' option - this is actually really useful to decide between a safe and a performant build method (XMLs must be crafted more carefully and are less flexible for the latter but if it fits all is fine)

(Be consistent about when to show it, no non-functional combo boxes)

Remember splitter sizes also when hiding/showing the Workflow - this makes toggling the Workflow via the menu much more user friendly

If a path that is referred to in the workflow is relative, it is now converted to absolute based on the location of the ini file. This is what makes the most sense and allows directly opening the results files.

This means that the PATH variable receives more locations where to look for the application that should be launched by the workflow. It is assumed that the workflow name is also used (all lowercase) in some potential directory names that could contain the executable for the said application.

Now the user can chose to either use as working directory the one of the ini file or the current one. The first elements of an enhanced way to find applications even not in the PATH have been laid out, it will now be customized for each platforms.

When the application was not found in PATH, it would fail to notify the user, thus letting the user believe "something" is running. It now properly reports to the user that the executable was not found.