Build lib Files with gcc on Windows

[CoolSpy3]

Description This PR supersedes #6740.

Currently, Windows import libraries (.lib files) are only being generated for some binaries. This makes it difficult to link to these binaries with the MSVC toolchain. This was previously done because generating these files requires listing all of there exports in a file, which had to be done by hand. ~~This PR updates the relevant Makefiles to use MinGW's dlltool to generate these export listings. These can then be compiled to import libraries by MSVC.~~

This PR updates the relevant Makefiles to generate the libraries with gcc, which does not have the aforementioned requirement. (Thanks to @Kreijstal for the suggestion!) From my understanding, these should provide the same functionality as the visual-cpp-generated files, but with two added benefits:

1. The generation is now fully automatic. This means that there is no need for new contributors to remember to export new symbols. This is especially helpful for the cpp library variants, which have name-mangled symbols. Atm, these have no explicit symbol listing, and thus, no generated import libraries.
2. As far as I can tell, the generation of import libraries was the build process's only dependency on the visual-cpp build tools. This means that after this change, the Visual Studio dependencies can be removed from the Makefiles and GitHub Actions scripts.

Combined with #6752, this makes the def files throughout the repo completely obsolete. I've deleted them in this PR, however, because of their additional use in the MATLAB sources test, this will make the sources tests fail until #6752 is merged.

The removal of Visual Studio and def files from the build process will also necessitate that those elements are removed from the Wiki. I will make those changes after this PR is merged.

Related Issues This pull-request fixes issue #6434.

Tasks Add the list of tasks of this PR.

• [x] Rewrite the existing builds to generate their import libraries with gcc
• [x] Remove the outdated parts of the build (visual-cpp and *.def files)
• [x] Check the symbols exported by the new files against the old ones and note any significant changes in this PR.
• [x] Update the changelog

[CoolSpy3]

I've checked the new files against the old ones, the changes are pretty minimal for the most part.

car.lib

• Now exports LIGHT_INDEX (an enum that's only accessible through private header files)
• No longer exports _wbu_car_initialization_is_possible (A non-existant function)

driver.lib

• Now exports LIGHT_INDEX (See above)
• Now exports some deprecated methods (These methods are still listed in the header files, so I agree with gcc's choice here.)

Controller.lib

• Now exports a bunch of functions from libraries and internal methods (see #6740 for details. Again, I believe this is okay.)
• No longer exports wb_range_finder_image_get_depth (This is a macro and should not be exported)

CppController.lib

I'm not going to parse the name-mangled nonsense here, but the old version was generated by the same method so the changes should be irrelevant. A quick scan shows that some new methods were added (likely additions to the cpp api since R2023b [which is what I was testing against]), and some std functions were removed.

Here's a zip containing the old and new export lists and diffs between the relevant files.

[lukicdarkoo]

@CoolSpy3 We have almost finished QA for the new release. I would avoid merging any new contributions (except bug fixes) until the new release is out.

[CoolSpy3]

Sounds good! Good luck on the next release 🚀 Can't wait :D

[CoolSpy3]

Note: Now that I think about it, the argument could be made that this should target develop rather than master. If that should be the case, let me know, and I can update the PR.

[CoolSpy3]

Very good. May I let you update the Wiki accordingly?

Will do!

Edit: Done!