autotools passes `LDFLAGS` automatically to the linker command. curl's
`lib/Makefile.am` customizes libcurl linker flags. In that
customization, it added `LDFLAGS` to the custom options. 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 patch deletes `LDFLAGS` from our customized options, leaving a
single copy of them as passed by autotools automatically.

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 might suggest a bug in either the linker or in `libtool`.
The curl build does indeed pass the list of detected libs via its own
`LIBCURL_LIBS` variable, which ends up before `LDFLAGS` on the `libtool`
command line, but it would seem to be the job of `libtool` to ensure
that even a buggy/peculiar linker gets the options in the order it's
expecting it. Especially because autotools passes `LDFLAGS` last, making
it hardly possibly to pass anything after it. Perhaps in the 10 years
since this issue, this already got a fix upstream.

IMO passing `LDFLAGS` twice to fix the above is a nuclear option with
unintended side-effects.

Closes #xxxxx

…BIN`

To allow passing `LDFLAGS` specific to libcurl (`CURL_LDFLAGS_LIB`)
and curl tool (`CURL_LDFLAGS_BIN`).

This makes it possible to build libcurl and curl with a single
invocation with lib- and tool-specific custom linker flags.

Such flag can be enabling `.map` files, a `.def` file for libcurl DLL,
controlling static/shared, incl. requesting a static curl tool (with
`-static-libtool-libs`) while building both shared and static libcurl.

curl-for-win uses the above and some more.

Closes #xxxxx