Fix build against current GNUstep core (libs-corebase, libs-quartzcore)

[pkgdemon]

Summary

Recent GNUstep core libraries (libs-corebase, libs-quartzcore) now declare
the Core Graphics types (CGPoint, CGSize, CGRect, CGAffineTransform,
etc.) themselves. Before this PR, libs-opal unconditionally redeclared the
same types, causing duplicate-definition build failures when libs-opal is
built alongside current libs-corebase or when libs-quartzcore is pulled in.

This also adjusts a couple of compiler flags so the current
clang/gcc defaults (stricter -Werror=int-conversion) don't break the build.

Changes

• Headers/CoreGraphics/CGBase.h — import Foundation/NSObject.h first
  in ObjC mode so CoreFoundation inline functions can resolve NSObject
  methods; add fallback CF* typedef stubs for builds without
  libs-corebase (guarded by __COREFOUNDATION_CFNUMBER_H__).
• Headers/CoreGraphics/CGGeometry.h and CGAffineTransform.h — guard
  the CG type declarations and NS*↔CG* bridge helpers with
  #ifndef CF_DEFINES_CG_TYPES so they're skipped when CoreFoundation
  already provides them.
• Source/OpalGraphics/GNUmakefile, Source/OpalText/GNUmakefile,
  Tests/GNUmakefile — add -Wno-error=int-conversion so the build
  doesn't fail on modern toolchains.

Compatibility

• With current libs-corebase / libs-quartzcore: types come from
  CoreFoundation; the guarded blocks are skipped; libs-opal builds cleanly.
• Without libs-corebase: the fallback stub typedefs kick in and the
  original CG type declarations are used, same as before.

Testing

Built cleanly against current GNUstep core on Devuan/Linux x86_64.
Ran the existing test suite in Tests/ (shapes, paths, gradients,
shadows, images) — all render correctly.

[pkgdemon]

@gcasa Here are fixes discussed in last GNUstep meeting.

[fredkiefer]

It would be great if you could work on fixing the issues that require -Wno-error=int-conversion to work around. But this should not block the merge of this change.
Could you please look into the failure of the check? I don't think that your change caused it, but it is always better to have a working pipeline before doing changes.

[pkgdemon]

It would be great if you could work on fixing the issues that require -Wno-error=int-conversion to work around. But this should not block the merge of this change. Could you please look into the failure of the check? I don't think that your change caused it, but it is always better to have a working pipeline before doing changes.

Hi @fredkiefer yes I am going to assume this workflow has been broken for some time. Should this projects GitHub actions workflow be updated to follow the pattern that libs-gui, libs-base uses? Those workflows do not use tools-scripts and that is where the breakage is now.

[fredkiefer]

Sounds good to me, but we can also merge this PR even before that, if it shows up to be too complicated to fix. Maybe a separate PR would be better either way.