autotools: avoid passing LDFLAGS twice for libcurl

[vszakats]

autotools passes LDFLAGS automatically linker commands. curl's
lib/Makefile.am customizes libcurl linker flags. In that
customization, it added LDFLAGS to the custom flags. This resulted
in passing LDFLAGS twice to the libtool command.

Most of the time this is benign, but some LDFLAGS options can break
the build when passed twice. One such example is passing .o files,
e.g. crt*.o files necessary when customizing the C runtime, e.g. for
MUSL builds.

Passing them twice resulted in duplicate symbol errors:

libtool: link:  clang-15 --target=aarch64-unknown-linux-musl [...] /usr/lib/aarch64-linux-musl/crt1.o [...] /usr/lib/aarch64-linux-musl/crt1.o [...]
ld.lld-15: error: duplicate symbol: _start
>>> defined at crt1.c
>>>            /usr/lib/aarch64-linux-musl/crt1.o:(.text+0x0)
>>> defined at crt1.c
>>>            /usr/lib/aarch64-linux-musl/crt1.o:(.text+0x0)
[...]
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This behaviour came with commit 1a59319
(2013-07-23) as a fix for bug https://curl.haxx.se/bug/view.cgi?id=1217.
The patch was a works-for-me hack that ended up merged in curl:
https://sourceforge.net/p/curl/bugs/1217/#06ef
With the root cause remaining unclear.

Perhaps the SUNPro 12 linker was sensitive to -L -l order, requiring
-L first? This would be unusual and suggests a bug in either the
linker or in libtool.

The curl build does pass the list of detected libs via its own
LIBCURL_LIBS variable, which ends up before LDFLAGS on the libtool
command line, but it's the job of libtool to ensure that even
a peculiar linker gets the options in the expected order. Also because
autotools passes LDFLAGS last, making it hardly possible to pass
anything after it.

Perhaps in the 10 years since this issue, this already got a fix
upstream.

This patch deletes LDFLAGS from our customized libcurl options,
leaving a single copy of them as passed by autotools automatically.

Reverts 1a59319
Closes #12310