Don't consider newer Apple compilers having "universal" byte order

I don't understand what the "universal" byte order thing tries to
say. Sure, Apple's compilers can produce fat binaries, i.e. containing
code for multiple architectures, which I guess might have differing
byte order. But I think the test for an -arch flag being present here
is backwards, surely if you specify -arch i386 for instance, then we
*know* that the byte order is little endian, not "universal".

Anyway, this broke ICU when built against MacOSX SDK 10.6 at least,
the ICU configury used wrong suffix for ICUDATA_NAME, and genbrk
failed in i18npool with a mysterious "can not initialize ICU.  status
= U_FILE_ACCESS_ERROR" message.

icu/icu4c-build.patch

@@ -39,6 +39,17 @@
  *-linux*|i*86-*-*bsd*|i*86-pc-gnu)
      if test "$GCC" = yes; then
          # We're using gcc, and the simple -a gcc command line works for genccode
+@@ -8001,8 +8001,9 @@
+ 	# Check for potential -arch flags.  It is not universal unless
+ 	# there are some -arch flags.  Note that *ppc* also matches
+ 	# ppc64.  This check is also rather less than ideal.
++	# Huh? This breaks the ICU build on MacOSX 10.6 at least --tml@iki.fi
+ 	case "${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}" in  #(
+-	  *-arch*ppc*|*-arch*i386*|*-arch*x86_64*) ac_cv_c_bigendian=universal;;
++	  # *-arch*ppc*|*-arch*i386*|*-arch*x86_64*) ac_cv_c_bigendian=universal;;
+ 	esac
+ else
+   $as_echo "$as_me: failed program was:" >&5
 @@ -11115,6 +1115,10 @@
      # wchar_t can be used
      CHECK_UTF16_STRING_RESULT="available"