cmake: add missing lib_lightgbm_swig.so to lightgbmlib.jar on linux

[shuttie]

A PR [cmake] [swig] use CMake's built-in file-copying mechanisms instead of 'cp' #6259 introduced a small build regression:

• before: for Linux, both lib_lightgbm.so and lib_lightgbm_swig.so were included into the JAR
• after: only lib_lightgbm.so is part of the JAR.

Lack of the SWIG wrapper makes it impossible to link to the library from the JVM. Mac and Windows builds do include the SWIG wrapper properly and are not affected by this regression.

This PR adds back the lib_lightgbm_swig.so library to the JAR build process on Linux. I'm maintaining the lightgbm4j library and find it very convenient to re-use your build artifacts :)

[shuttie]

The failure on Microsoft.LightGBM/QEMU_multiarch bdist CI test seem to be unrelated to the change.

[jameslamb]

You're right, we have a project-wide blocking CI issue right now: #6509.

We'll come back and review this once we've fixed that. Thanks so much for taking the time to contribute, and sorry about breaking that in #6259 😭

[jameslamb]

Thanks very much for the help!

The SWIG builds here haven't been very actively developed (https://github.com/microsoft/LightGBM/commits/master/swig), and the only tests we run on them is just "does compilation succeed".

LightGBM/.ci/test.sh

Lines 83 to 95 in f811c82

	if [[ $TASK == "swig" ]]; then
	cmake -B build -S . -DUSE_SWIG=ON
	cmake --build build -j4 || exit 1
	if [[ $OS_NAME == "linux" ]] && [[ $COMPILER == "gcc" ]]; then
	objdump -T ./lib_lightgbm.so > ./objdump.log || exit 1
	objdump -T ./lib_lightgbm_swig.so >> ./objdump.log || exit 1
	python ./helpers/check_dynamic_dependencies.py ./objdump.log || exit 1
	fi
	if [[ $PRODUCES_ARTIFACTS == "true" ]]; then
	cp ./build/lightgbmlib.jar $BUILD_ARTIFACTSTAGINGDIRECTORY/lightgbmlib_$OS_NAME.jar
	fi
	exit 0
	fi

If you have ideas for improving that, we'd welcome the help! For example, I think a some Java unit tests (even just very minimal ones that train a small regression model and maybe generate some predictions) would have caught this bug, and would catch future bugs before they make it to a release. We don't really have much Java experience on the maintainer team, so we'd welcome the help adding something like that (in later PRs) if it interests you.