Enable deterministic builds and embed untracked sources in NuGet packages

[slang25]

Description

Enable Deterministic and EmbedUntrackedSources MSBuild properties across all projects that produce NuGet packages.

• Deterministic: Ensures the compiler produces byte-identical output for the same inputs, enabling reproducible builds.
• EmbedUntrackedSources: Embeds source files not tracked by source control (e.g. auto-generated code) into the PDB. This complements the existing SourceLink support so that consumers can debug into generated sources that can't be fetched from GitHub.

Properties are added to sdk/Directory.Build.props, extensions/Directory.Build.props, and the 5 per-extension Directory.Build.props files that shadow the parent.

Motivation and Context

The NuGet packages published by this repository already include SourceLink, allowing sources to be mapped back to their GitHub repo source files. However:

1. Untracked/generated sources are not embedded in the PDB, so stepping into generated code during debugging fails.
2. The Deterministic flag is not explicitly set, which means builds may not be reproducible across machines.

Testing

These are declarative MSBuild property changes. They can be verified by:

1. Building any SDK or extension project and inspecting the PDB with dotnet tool run sourcelink print-json to confirm SourceLink metadata.
2. Checking the PDB with a tool like MetadataTools to confirm untracked sources are embedded.
3. Building twice and comparing output binaries to verify determinism.

Breaking Changes Assessment

No breaking changes. These properties affect compiler and PDB output only — they do not change the runtime behavior or public API surface of any assembly.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[dscpinheiro]

This is somewhat related to #4110, right? I did give it a try when that issue was created, but even after applying Martin's suggestions dotnet-validate still complained after I rebuilt the SDK in our build system...

I only got those warnings to go away after I manually changed the SDK not to use the .nuspec file (moving the properties to the csproj files) and used dotnet pack (instead of what we do today, which is using https://github.com/aws/aws-sdk-net/tree/main/sdk/.nuget). So I think we need to make some other changes on our end before this is resolved.

[slang25]

@dscpinheiro Yes it's basically #4110

I won't go into too much detail about what I'm trying to do, but I writing some meta-programing tools, and it's helpful if packages are "complete" and contain links to source, or embed untracked source files.

You'll see what's missing if you go here:
https://nuget.info/packages/AWSSDK.Core/4.0.3.15

As I understand, this should still work with the nuspec approach, because it's about the symbols/dlls and you are already getting the sourcelink document embedded there, it's just that the symbols don't include the untracked files, and the paths are deterministic (/_/ etc...).

So it should be a case of tweaking the build step. Are the actual release build scripts part of the repo or are these private?