Behave more consistently when target arch %optflags are not defined

You're about to fall into a deep dark hole, proceed at your own risk.

When building for a target architecture with no defined %optflags
(such as noarch), one would think that %optflags would be empty. Not so in
rpm, instead we get %optflags for the detected architecture, and there
are packages which rely on this behavior. And in this particular dark
corner, buildarchtranslate is not applied so one can get drastically
different %optflags than you'd get without an explicit --target, on the
same system. Which can break builds.

This behavior is just WRONG, %optflags should always reflect the target
architecture. But as long as there's no %_host_optflags, lets at least try
to be consistent about it. When we fall back to detected architecture
%optflags, at least use the ones after buildarchtranslate to return
consistent data within a host.

This supposedly fixes the case where our newly added x86_64
subarchitecture definitions haven't been overridden in vendor config and
somebody's noarch package uses cmake to install data, and falls over due
to nonsensical optflags from rpm.

Initial report: https://bugzilla.redhat.com/show_bug.cgi?id=2231727

lib/rpmrc.c

@@ -1685,6 +1685,14 @@ static void rpmRebuildTargetVars(rpmrcCtx ctx,
  * XXX Make sure that per-arch optflags is initialized correctly.
  */
   { const char *optflags = rpmGetVarArch(ctx, RPMVAR_OPTFLAGS, ca);
+    /*
+     * If not defined for the target arch, fall back to current arch
+     * definitions, with buildarchtranslate applied. This is WRONG
+     * but it's what we've always done, except for buildarchtranslate.
+     */
+    if (optflags == NULL) {
+	optflags = rpmGetVarArch(ctx, RPMVAR_OPTFLAGS, NULL);
+    }
     if (optflags != NULL) {
 	rpmPopMacro(NULL, "optflags");
 	rpmPushMacro(NULL, "optflags", NULL, optflags, RMIL_RPMRC);