Robustly handling the FMU files with symlinks in binaries

[ven-k]

fmuChecker.linux64 fails to recognize and read the FMUs that contain symbolic links in binaries

The zip by default converts the symbolic links to actual target files and deflates and stores.
Hence most of the time when zip -r destname.zip src_dir is called the symlinks in src_dir (/binaries/linux64) are replaced with the actual target files. Thus significantly increasing the size and redundancy in the contents

Whenever too many, and large binaries are involved the size difference becomes very pronounced. It is necessary that we allow symbolic links when libs in "binaries" are versioned.

I've attached a sample BouncingBallTestFMUs.zip with
a: BouncingBalls test fmu from fmi-cross-check
b: one with a symbolic link placed in "BouncingBallsWithSymlink/binaries/linux64" which was zipped with

cd BouncingBallsWithSymlink
zip -r --symlink BouncingBallsWithSymlink.fmu .

It results in following error

root@yoda:~/FMUChecker/build# ./fmuCheck.linux64  -n 5 -s 1 -l 1 -k me ./test-fmus/BouncingBallWithSymlink.fmu
"time","h","v"

[FATAL][FMICAPI] Could not load the DLL: /tmp/fmucktmpaZT8s2/binaries/linux64/BouncingBall.so: file too short
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for ME.
FMU check summary:
FMU reported:
        0 warning(s) and error(s)

Checker reported:
        Warnings and non-critical errors were ignored (log level: FATAL)
        2 Fatal error(s) occurred during processing

[ven-k]

This would significantly reduce size of FMUs built with Julia, whose binaries consists of symlinks.
You can find a practical example of such fmus with and without symlinks here