Add CFLAGS and CXXFLAGS to macros.flatpak, to match LDFLAGS
    
    I ran into this when building java-1.8.0-openjdk, but it looks like it could be
    a wider problem:
    
    The java-1.8.0-openjdk configure, for "checking whether we are cross compiling",
    contains a call effectively equivalent to `gcc $LDFLAGS conftest.c` with
    conftest.c contents effectively equivaluent to some
    
      #include <stdio.h>
      int main() {
        FILE * f = fopen("conftest.out", "w");
        return 0;
      }
    
    With empty LDFLAGS that works fine.  But macros.flatpak injects
    
      %__global_ldflags %{build_ldflags} -L%{_libdir}
    
        LDFLAGS="%{?__global_ldflags}"\
        export LDFLAGS\
    
    Those LDFLAGS include -specs=/usr/lib/rpm/redhat/redhat-hardened-ld and
    /usr/lib/rpm/redhat/redhat-hardened-ld causes -pie to be added to the linker
    flags.
    
    The corresponding -fPIE that would be added to the compiler flags via
    /usr/lib/rpm/redhat/redhat-hardened-cc1 and
    -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 is not present, however, because
    macros.flatpak did not correspondingly inject
    
      CFLAGS="%{?__global_compiler_flags}"\
      export CFLAGS\
    
    That caused the above `gcc $LDFLAGS conftest.c` to fail with
    
      /usr/bin/ld: /tmp/ccQdOErY.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
      /usr/bin/ld: final link failed: nonrepresentable section on output
      collect2: error: ld returned 1 exit status
    
    A similar problem appears later during java-1.8.0-openjdk's configure with g++
    instead of gcc, which in turn is fixed by correspondingly injecting
    
      CXXFLAGS="%{?__global_compiler_flags}"\
      export CXXFLAGS\