Added rules for DLLs from MSYS2.

[Paebbels]

This PR tries to solve #2314.

@tgingold
Open questions:

• How to enable standalone mode?
  ⇒ Use a separate make target called standalone
  ⇒ add --enable-standalone/--disable-standalone to ./configure as well as some install.mcode.libs.true/install.mcode.libs.false and uninstall.mcode.libs.true/uninstall.mcode.libs.false targets.
• How to get the GNAT major version?
  This version number is used in the DLL filename.
  ⇒ use a glob pattern like libgnat-*.dll. In MSYS2, only one version is installed. No parallel versions exist.
• How to get the LLVM major version?
  This version number is used in the DLL filename.
  ⇒ use a glob pattern like libLLVM-*.dll. In MSYS2, only one version is installed. No parallel versions exist.
• How to distinguish 32-bit MSYS2 environments (here MinGW32) from 64-bit environments (MinGW64 or UCRT64).
  One environment uses dw2 the other seh exception handling.
  ⇒ ./configure is used to derive LIBGCC_KIND from build variable.
• How to check if standalone is used with non mcode backends.
• How to check if standalone is not used with MSYS2.
  → Maybe check against build variable?

[Paebbels]

I saw, you're using some true/false flags via make target names. Maybe it would be cleaner to not add a new make target, but offer a configure option like --standalone, which then sets a true/false.

[Paebbels]

The latest commit contains this:

• --enable/--disable-standalone.
• new variable LIBGCC_KIND in configure derived from build.

I'm now locally testing. I assume we should add a check if standalone is used with another backend than mcode and if not used in MSYS2.

[tgingold]

I have created #2320 to add new makefile targets.

Should we rewrite Test.yml to build standalone windows packages without reusing the pacman package ?
Or also create the standalone windows packages while creating the msys packages ?

[Paebbels]

Should we rewrite Test.yml to build standalone windows packages without reusing the pacman package ?

The current solution for packaging standalone mcode variants is a "dirty hack" I made with @umarcor. We used MSYS2 packages, because they contain all needed files, so we didn't need to figure out what to repackage for standalone.

So we used that package, installed it, added die DLLs and then packaged it again as ZIP.

If we could install GHDL mcode directly including DLLs and use this directory for creating a ZIP file, it would simplify a lot and reduce CI job dependencies.

[tgingold]

I am not sure to understand how you want to create the standalone package. There are multiple solutions: 1. the current one: unpack the msys pacman package, add dlls, zip 2. mixed: after building the pacman package, add the dlls and zip. So during the same jobs two artifacts are produced. 3. full jobs: build mcode, add dlls and create the zip. I don't really like 3), as it will be difficult to test. I am ok with 1 and 2. But the real question is how to produce the python wheel for #2313.