Again, no -fstack-protector-strong for gcc3_linux_aarch64/cpp2uno.cxx

8d12e4ec "No -fstack-protect-strong for
gcc3_linux_aarch64/cpp2uno.cxx vtableSlotCall" had done that in the past (so
that setting up the x0/x1 return registers in vtableSlotCall is not clobbered
by the stack protector code), but gbuild details have apparently changed in the
meantime, so that gb_CXXFLAGS_COMMON's -fstack-protector-strong now ends up on
the compiler command line before what is covered by gb_Library_add_cxxobjects's
argument, so didn't get subst'ed to -fstack-protector.  That caused Flathub
aarch64 builds to fail in CustomTarget_testtools/uno_test.

However, if both -fstack-protector-strong and -fstack-protector are present on
the command line, the second apparently wins, so use that hack for now.
(-fstack-protector-strong is only available since GCC 4.9, but -fstack-protector
is already available in our current baseline GCC 4.8.1, and even for a build on
that baseline it wouldn't hurt if cpp2uno.cxx was explicitly built with
-fstack-protector even if none of the other files were built with
-fstack-protector-strong.)

Change-Id: I9d78d2e5b08b7c0a4adb1531b482cd43617886f7

bridges/Library_cpp_uno.mk

@@ -34,9 +34,8 @@ bridge_exception_objects := abi callvirtualfunction uno2cpp
 
 $(eval $(call gb_Library_add_cxxobjects,$(gb_CPPU_ENV)_uno, \
     bridges/source/cpp_uno/$(bridges_SELECTED_BRIDGE)/cpp2uno, \
-    $(subst -fstack-protector-strong,-fstack-protector, \
-        $(gb_LinkTarget_EXCEPTIONFLAGS) \
-        $(call gb_LinkTarget__get_cxxflags,$(gb_CPPU_ENV)_uno)) \
+    $(gb_LinkTarget_EXCEPTIONFLAGS) \
+    $(call gb_LinkTarget__get_cxxflags,$(gb_CPPU_ENV)_uno) -fstack-protector \
 ))
 endif