Restore environment after make to avoid mixing-up linker flags

[jre-lsft]

At first I considered just replacing the whole config_link_backup logic in vcpkg_build_make with vcpkg_{backup,restore}_env_variables(VARS _LINK_).
Unfortunately, I soon realized that the same logic exists in vcpkg_configure_make, only that in this case vcpkg_backup_env_variables(VARS _LINK_) is already used in the same scope.
Since vcpkg_{backup,restore}_env_variables() relies on the enclosing variable scope, which makes nested calls (within the same function) difficult, I kept the config_link_backup logic (for now).

Note that thanks to CMake 3.25 and block() scopes, nested calls to vcpkg_{backup,restore}_env_variables() are now actually an option.
However, even though vcpkg already uses CMake 3.25, I wasn't sure if this meant that backwards compatibility was not an issue.

Fixes #29983.

[jre-lsft]

@microsoft-github-policy-service agree company="elusoft GmbH"

[Cheney-W]

You could get the error logs from https://dev.azure.com/vcpkg/public/_build/results?buildId=86250&view=artifacts&pathAsName=false&type=publishedArtifacts

[jre-lsft]

Yeah, I really shouldn't have made that second set of changes.
They are not relevant to the issue I was facing and are only related in that the stray vcpkg_backup_env_vars(VARS _CL_ _LINK_) caught my attention, as it was the reason I did not to use vcpkg_{backup,restore}_env_vars() to save/restore the build configuration specific changes to _LINK_ in the foreach() loops.
Seeing that there was no corresponding vcpkg_restore_env_vars(VARS _CL_ _LINK_) I jumped to conclusions.
Now, after re-reading the comments, I realize that the UWP-related modifications to _CL_ and _LINK_ are intentionally "leaked".
However, even in that case, it occurs to me that the stray vcpkg_backup_env_vars(VARS _CL_ _LINK_) doesn't make much sense, but perhaps someone more familiar with the code base could take a second look.
Anyway, I've removed the irrelevant changes, please forgive my ignorance.

[dan-shaw]

Why do we unset this variable if it was not set?

[jre-lsft]

(In the following, I'll assume that both this variable and it are referring to config_link_backup. However, if it refers to LINK_ENV_${cmake_buildtype}, you'll have to make some mental adjustments.)

But we don't know that, do we?
Note that I have moved the unset() up from the second if() clause.
As a result, we might observe the value of config_link_backup from the first iteration in the second iteration of the foreach() loop.
Regardless, and to be pedantic, we don't even know that config_link_backup is unset when the foreach() loop is first entered, it could exist in the global scope, too.
Call me paranoid.

The goal of this PR is to make sure that the value of the _LINK_ environment variable is restored in the second if() clause if and only if it was changed in the first if() clause.
There are certainly several ways to implement this logic in a semantically equivalent way.
For example, we could not look at config_link_backup at all in the second if() condition and instead use the exact same condition as in the first if() clause, i.e. if(LINK_ENV_${cmake_buildtype}) (assuming LINK_ENV_${cmake_buildtype} itself is not modified between the first and the second if() clause).
I chose not to do this because I felt that it would increase, however slightly, the chances that the two conditions would become out of sync over time, breaking the if and only if requirement.
In other words: I decided to go with the proposed implementation because it (kind of) keeps both decisions, whether to modify _LINK_ in the first place and whether to restore its value, close together in the first if() clause, by encoding the latter decision into config_link_backup (it's either DEFINED or not).