Submodules src/Modules/Lombiq.AuditTrailExtensions, tools/Lombiq.GitHub.Actions updated

Submodule tools/Lombiq.GitHub.Actions:
    > 3aec50ad - Always uploading CompatibilitySuppressions
    > 919c1b0d - Running dotnet pack twice
    > 338d142e - Syntax
    > dbdaec59 - Notice message
    > e7fb4a47 - Uploading CompatibilitySuppressions files
    > 551ffc67 - We need it. Docs and refactoring.
    > 57e6075c - Pointing GHA to issue branch
    > 0057263c - Why do we need to add the baseline package
    > 935f30c4 - Passing indicate-breaking-changes around
    > 8d76e364 - Basics

Author: Piedone

Readme.md

@@ -128,11 +128,7 @@ When adding a new extension, or significant new features to existing extensions,
 - Open a pull request in this repository for every submodule pull request. That way, static code analysis and complex tests can run. If you forget to do so, a check in the submodule will fail. Once you've created the PR here, just click "Re-run jobs" in your submodule.
 - If you see build errors under your pull request then check out its details: It will send you to the failed step in the Actions tab. You can also click on the "Summary" on the sidebar to download the artifacts (logs, screenshots, etc) and in case of failed UI tests you find the annotations linking to which test failed.
 - Open a pull request for all but trivial changes (like typos) so we can nicely track them, including when generating release notes for the next release.
-- If you introduce .NET breaking changes, the Validate NuGet Publish workflow will fail due to [baseline package validation](https://learn.microsoft.com/en-us/dotnet/fundamentals/apicompat/package-validation/baseline-version-validator). Preferably, adjust the change to not be breaking if possible; if it has to be a breaking change, then you’ll need to create a _CompatibilitySuppressions.xml_ file to mark it as deliberate, what you can do with the following command:
-
-```powershell
-dotnet pack /p:EnablePackageValidation=true /p:PackageValidationBaselineVersion=<current version, like 1.2.3> /p:Version=<the next patch version, like 1.2.4> /p:NuGetBuild=true /p:GenerateCompatibilitySuppressionFile=true
-```
+- If you introduce .NET breaking changes, the Validate NuGet Publish workflow will fail due to [baseline package validation](https://learn.microsoft.com/en-us/dotnet/fundamentals/apicompat/package-validation/baseline-version-validator). Preferably, adjust the change to not be breaking if possible; if it has to be a breaking change, then add a _CompatibilitySuppressions.xml_ file to mark it as deliberate. This will be generated by the workflow and made downloadable as an artifact for your convenience.
 
 ### .NET and Orchard Core version support policy