cmake: De-duplicate libraries on link lines opportunistically

[hebasto]

This PR resolves "ignoring duplicate libraries" linker warnings on macOS:

[892/895] Linking CXX executable src/test/test_bitcoin
ld: warning: ignoring duplicate libraries: 'src/secp256k1/lib/libsecp256k1.a'
<snip>
[894/895] Linking CXX executable src/test/fuzz/fuzz
ld: warning: ignoring duplicate libraries: 'libleveldb.a', 'libminisketch.a', 'src/libbitcoin_common.a', 'src/secp256k1/lib/libsecp256k1.a', 'src/univalue/libunivalue.a', 'src/util/libbitcoin_util.a'

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31504.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #30901 (cmake: Revamp handling of data files for {test,bench}_bitcoin targets by hebasto)
• #28792 (Embed default ASMap as binary dump header file by fjahr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[theuni]

I saw this new feature recently as well and had the opposite thought.. I'm not sure how much I trust CMake's linker feature logic as it seems to be based on the target as opposed to the linker itself. I have a slight preference for setting this to the old policy just so that we're always in control. As long as dupe libs are just warnings, I don't see any harm.

[fanquake]

Also not sure. Seems like this was introduced in 3.29, but then the behaviour was changed again 2 versions later in 3.31. Would we be opting into that as well? Then, depending on the version, we'd potentially have CMake behaving 3 different ways at link time. Maybe we should wait on doing anything until they've figured out what they are doing.