optee-os-stm32mp: Fix build when sysroot dependencies are bumped

The build `make` metadata tracks sysroot dependencies as file suitable
for `make` to get the dependecies of the main source file. This is done
with a combination of preprocessor options: -MD and -MF. These files are
suffixed `.d`. When these files are generated with paths that include
the version of the dependency, later dependecy version bumps will
invalidate these paths as the sysroot gets regenerated.

For example, gcc headers file stdbool.h is defined as the dependecy to:
[BUILD]/tmp/work/stm32mp1_av96-poky-linux-musleabi/optee-os-stm32mp/3.12.0.r1-r0/recipe-sysroot-native/usr/lib/arm-poky-linux-musleabi/gcc/arm-poky-linux-musleabi/11.1.1/include/stdbool.h

This include the gcc version 11.1.1 in its path. When gcc is upgraded,
sysroot is regenerated, configure and compile retriggered but compile
will reuse the generated `.d` file from the old gcc version, hence
failing to find the header mentioned above (as the gcc version changed).

This recipe uses an out-of-tree build so the easiest and most effective
fix it to just clean B once configure is triggered (retriggered). This
will force make to regenerate the dependency files as per the new paths
in the sysroot (assuming a sysroot update).

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

meta-ohos-staging/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend

+# This is only safe because this recipes uses out-of-tree builds. The package's
+# make design caches sysroot paths as make dependencies (see the .d files).
+# Some of these paths are versioned (gcc for example) so recompiling after a
+# gcc bump would make those dependencies fail. Forcing a clean build directory
+# when configure task is invalidated (which happens when native sysroot is
+# regenerated), fixes the dependency issue.
+do_configure[cleandirs] = "${B}"