Support current system libgd

[montj2]

This makes --with-sys-gd work with current libgd instead of silently falling
back to the embedded gd copy.

Changes:

• probe for the public gdImageSetClip API instead of the private
  gdClipSetAdd / gdft_draw_bitmap symbols
• define HAVE_SYS_GD and switch the xgd clipping helpers to public libgd APIs
• flatten exported GD image pixels for system libgd, which exposes tpixels
  rows but not libwmf's private contiguous _tpixels backing store
• link libwmf.la against the external libraries that bundled libgd.la used
  to pull in transitively

Context:

• Debian has longstanding embedded-libgd bugs open as Debian #382511 and
  Debian #635328
• this is the same embedded-copy concern discussed in GitHub issue Do not embded libgd #5

One behavioral note: public libgd only exposes a single clip rectangle, so the
system-gd path collapses multi-rectangle WMF clip regions to a bounding box.
That keeps the system-gd build working with the public API while preserving the
existing multi-rectangle behavior for the bundled fallback.

Validation on Debian unstable/arm64:

• autoreconf -fiv
• ./configure --with-sys-gd
• make -j1 V=1
• make -j1 V=1 check
• result: Support for GD: sys
• result: PASS: check-examples.sh

A macOS build would also be useful here, given the earlier issue discussion
around macOS build problems.

[montj2]

This is needed because the bundled src/extra/gd/libgd.la used to pull several dependency libraries into the final link indirectly. When --with-sys-gd is used,
LIBGD becomes empty and that transitive link path disappears, so libwmf.la needs the same external dependency set explicitly.