[Fix] - wholearchive should not cause multiple symbol definition.

[nickclark2016]

What does this PR do?

In the current iteration of wholearchive, if a library is listed both in links and wholearchive, it may cause multiple symbol definition.

How does this PR change Premake's behavior?

If a library (system or sibling projects) is listed in both the links and wholearchive section, the wholearchive specification will take precedence.

Behavior:

• Sibling library in links only -- Build dependency and links library (existing behavior)
• System library in links only -- Links library (existing behavior)
• Sibling library in wholearchive only -- Links library, includes all symbols/objects (existing behavior)
• System library in wholearchive only -- Links library, includes all symbols/objects (existing behavior)
• Sibling library in both links and wholearchive -- Build dependency and link library, including all symbols/objects. Only the single wholearchive linker input is emitted for the library, dropping the one from links.
• System library in both links and wholearchive -- Link library, including all symbols/objects. Only the single wholearchive linker input is emitted for the library, dropping the one from links.

Anything else we should know?

Other alternatives:

• Provide wholearchive with the same dependency generation capability as links
• Move wholearchive to be similar to :static and :shared suffixes (discussed in past with initial implementation of API, turned down)

Additionally, pinned the CI actions to windows-2022 to fix CI failures with GH Runner changes to what is windows-latest.

Did you check all the boxes?

• Focus on a single fix or feature; remove any unrelated formatting or code changes
• Add unit tests showing fix or feature works; all tests pass
• Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• Follow our coding conventions
• Minimize the number of commits
• Align documentation to your changes

You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!