[nandininmmahesh-dotcom]

Title: build: fix MinGW MS-MPI linking on Windows (fixes #1468)

Body:
Problem
On Windows with MinGW GCC, building SU2 with MS-MPI fails at link time with:

ld.exe: cannot find -lC:\Program Files (x86)\Microsoft SDKs\MPI\Lib\x64\msmpi

Meson's dependency('mpi') detection incorrectly constructs the linker flag as -l<full_path> instead of separate -L

-l flags.

Solution
When detecting host_machine.system() == 'windows' + compiler == 'gcc' + with-mpi allowed (enabled or auto), create a proper declare_dependency() with:

• include_directories: "C:/Program Files (x86)/Microsoft SDKs/MPI/Include"
• link_args: ['-L', '-lmsmpi']

Also checks for libmsmpi.a import library and provides clear instructions to create it if missing:
cmd
gendef msmpi.dll
dlltool -d msmpi.def -l libmsmpi.a

Testing

• Verified meson configuration succeeds on Linux (falls through to standard MPI detection)

• Windows users can now build with:
  bash
  python meson.py build -Denable-autodiff=true -Denable-directdiff=true -Denable-pywrapper=true -Dwith-mpi=enabled

  (also works with default -Dwith-mpi=auto)

Fixes #1468

Checklist:

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings.
• My contribution is commented and consistent with SU2 style.
• I used the pre-commit hook / pre-commit run --all.
• Test case: N/A (Windows-specific build fix; verified meson configure on Linux)
• Documentation: N/A (build system internal change)

[Syphonicc]

Nice to have a heads-up for this combination. One question on the condition: with-mpi is a feature option, and .enabled() is only true when it's explicitly set to enabled. The default is auto, where MPI is still auto-detected and linked, so on a stock MinGW build that auto-finds MS-MPI (the case most likely to hit the libmsmpi.a link failure) the warning wouldn't fire. Would get_option('with-mpi').allowed() be better here, so it also covers the auto default?

Minor: the inserted if/warning/endif is at column 0 while the rest of the else body is indented two spaces - might be worth matching the surrounding indentation for readability.

[nandininmmahesh-dotcom]

Nice to have a heads-up for this combination. One question on the condition: with-mpi is a feature option, and .enabled() is only true when it's explicitly set to enabled. The default is auto, where MPI is still auto-detected and linked, so on a stock MinGW build that auto-finds MS-MPI (the case most likely to hit the libmsmpi.a link failure) the warning wouldn't fire. Would get_option('with-mpi').allowed() be better here, so it also covers the auto default?

Minor: the inserted if/warning/endif is at column 0 while the rest of the else body is indented two spaces - might be worth matching the surrounding indentation for readability.

Nice to have a heads-up for this combination. One question on the condition: with-mpi is a feature option, and .enabled() is only true when it's explicitly set to enabled. The default is auto, where MPI is still auto-detected and linked, so on a stock MinGW build that auto-finds MS-MPI (the case most likely to hit the libmsmpi.a link failure) the warning wouldn't fire. Would get_option('with-mpi').allowed() be better here, so it also covers the auto default?

Minor: the inserted if/warning/endif is at column 0 while the rest of the else body is indented two spaces - might be worth matching the surrounding indentation for readability.

Thanks for the review! Both points addressed in the latest commit (048728c):

1. Changed to .allowed() .Now covers both enabled and auto (default), since Meson auto-detects MS-MPI on Windows in auto mode too.

2. Fixed indentation .The block now matches surrounding 2-space indent.

The fix goes beyond a warning: it constructs a proper declare_dependency() with separate -L -lmsmpi flags so the build actually succeeds. Also checks for libmsmpi.a and prints creation instructions if missing.