synocli-devel updates and republish for x25 nas

[th0ma7]

Description

This PR introduces:

1. infrastructure fixes to prevent build environment leakage in spksrc, and updates the synocli-devel package to ensure correct builds and packaging.
2. Fix runpath so native binaries are relocatable (specific to CMake)
3. cross-cmake.mk: Disable CMAKE_BUILD_WITH_INSTALL_RPATH to avoid build-time executables to use the same RPATH as the cross-compiled bin|lib
4. update various synocli-devel dependencies targetting notably x25 platforms as package was never re-released.

Changes

1. Prevent build environment leakage

Several build failures were traced back to toolchain and build variables leaking across dependency boundaries, especially when mixing different build systems (autotools, CMake or Meson builds).

In particular:

Variables such as CC, CXX, CFLAGS, LDFLAGS, STRIP, etc. were implicitly exported even when they should not be. This is an historic behavior of spksrc as it used to only be supporting autotools and manual build types until I added CMake and meson much later on. This caused target-built binaries to be executed as native tools, leading to errors such as Exec format error (e.g. llvm-min-tblgen being built for the target instead of the host).

Changes:

• Introduce an explicit DEFAULT_ENV selector to control which build environment is initialized.
• Prevent automatic inclusion of autotools-related variables unless explicitly required.
• Ensure that build environments do not propagate into dependent packages unless intended.
• Fix meta packages (e.g. cross/llvm) to select dependencies without initializing any build environment.

This finally allows complex compilation such as llvm to avoid using CC and CXX content (as now inexistant in CMake) for compiling NATIVE in-build tools, and in turn avoid the need of keeping around native/llvm-9.0 for instance.

Worth noting that some leakage might still occur when going through the dependencies as the code is still as follow:

        @set -e; \
        for depend in $(filter-out native/%,$(TOOLKIT_DEPEND) $(BUILD_DEPENDS) $(DEPENDS)); \
        do                          \ 
          env $(ENV) $(MAKE) -C ../../$$depend ; \
        done

Although impact should be minimal considering:

1. most of the depencies now uses CMake or Meson
2. only a fraction (if any) might end-up being called as a dependency of autotools type build primary source
3. from this fraction only exceptions requires to compile NATIVE in-build targets

Thus chances of hiting such remaining occurence is extremely low but I'll consider reviewing this remaining logic into a subsequet PR when time allows it.

While this is a rather long description of what this change is about, there shouldn't be any changes noticed from a user experience with exception that:

1. background CMake and Meson environments are now mostly "empty" besides basics framework variables left-over in $(WORK_DIR)/tc_var.mk
2. strip is now resolved directly from the target toolchain when available, instead of relying on autotools environment variables. This avoids failures when autotools is not in use, while remaining compatible with build types.
3. generation of additional environment files (namely autotools_vars, tc_flags and rust_vars) compilation:

===>  BUILDING package for arch aarch64-7.1 with SynoCommunity toolchain
env make --no-print-directory tc_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.mk 2>/dev/null;
env make --no-print-directory autotools_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.autotools.mk 2>/dev/null;
env make --no-print-directory tc_flags > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.flags.mk 2>/dev/null;
env make --no-print-directory rust_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.rust.mk 2>/dev/null;
env make --no-print-directory cmake_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.cmake 2>/dev/null;
env make --no-print-directory meson_cross_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.meson-cross 2>/dev/null;
env make --no-print-directory meson_native_vars > /spksrc/toolchain/syno-aarch64-7.1/work/tc_vars.meson-native 2>/dev/null;

2. Fix runpath so native binaries are relocatable

For native build use -DCMAKE_INSTALL_RPATH='$$ORIGIN/../lib' which allows any binary to be relocatable. Otherwise without this fix we needed to set LD_LIBRARY_PATH=<path> in order for it to run properly.

3. cross-cmake.mk: Disable CMAKE_BUILD_WITH_INSTALL_RPATH

This causes the build-time executables to use the same RPATH as the cross-compiled bin|lib expected to run in the destination installation path causing them to fail when executed as unable to find their relative native libraries they were built against.

4. synocli-devel package updates:

• llvm-9.0: Usage of native is no longer necessary
• llvm-latest: Update from 16.0.6 to 21.1.8
• gdb-latest: Update from version 14.2 to 17.1 (DSM7 only)
• automake: Update from version 1.16.5 to 1.18.1
• binutils: Update from version 2.42 to 2.45
• strace: Update from version 6.9 to 6.18
• Addition of z3 to llvm buils: Add version 4.7 for gcc<=4.9 and 4.11 for newer gcc

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[th0ma7]

@hgy59 and @mreid-tt if you can have a review of this PR and in particular if you have any questions related to the framework changes involved. I tried to be as meticulous as possible to document the changes but let me know if it needs more explanations.

As well, now that this is finally done (was long over-due in my todo list and will be curious if this has impacts over #6867) - I have numerous smaller changes to do to the framework. I intend to push these other individually so it makes it easy to find where said regression was injected in the framework.

Lastly, I'm doing a few more tests on my end to confirm the obvious candidates haven't been impacted with this change (and will need to rebase against master to include @mreid-tt recent python fix to complete my testing).