Update Steamworks.NET

[roblabla]

This allows mods to make use of the newer features provided by Steamworks.NET. This is a requirement of my mod providing Steam Game Recording Integration.

Needs EverestAPI/Everest-libs#5 This PR is merged!

We're not updating to the very latest Steamworks.NET as it contains a breaking change that breaks Celeste (same as rlabrecque/Steamworks.NET#709). Fixing that would be relatively easy to do (just needs to nop out the call to SteamUserStats.RequestCurrentStats() in celeste's Stats.MakeRequest), but given my use-case doesn't need the newer functionality offered by the very latest Steamworks, I opted for the path of least resistance.

The largest part of the change is in the MiniInstaller. It does two things:

1. It copies the actual implementation dll of Steamworks.NET from lib-ext to the correct location to be picked up by Celeste.
2. It ignores Steamworks.NET in the ConvertToNETCore call. This is because otherwise, it would overwrite the previously copied Steamworks.NET with the version found in the orig folder, breaking everything.

I verified it works on Windows 64-bit and macOS (both Steam builds).

Fixes #860

[roblabla]

Well, this is annoying. Because I added Steamworks.NET as a PackageReference, a reference assembly gets added to the output. This is not a huge problem for the everest build, as it gets overwritten with the correct assembly. What kinda sucks though is that this reference assembly will overwrite the original Steamworks.NET.dll, which means it will end up in the orig folder, breaking the unmodded game build.

I looked for a way to massage dotnet publish into not providing that reference assembly, but couldn't find one (to be clear, I may have overlooked something - I don't do a whole lot of C#).

I can see two ways to fix this:

1. Don't use nuget for the Steamworks.NET dependency. I could instead add Steamworks.NET.dll in libs-ext (along with steam_api). This way, it'd get copied by the MiniInstaller as necessary. This would require updating lib-stripped as well.
2. Provide the original Steamworks.NET in libs-ext/lib-vanilla. This way, the installer would overwrite the Reference Assembly with the original file.

For now, I think I'll try pursuing the first option.

[roblabla]

All fixed. Steamworks.NET.dll is now copied from lib-ext, so there's no more shenanigans going on with the orig directory.

[roblabla]

The everest-libs PR got merged, this is read for review.

[SnipUndercover]

I'll rerun the pipeline since it errored out.

[SnipUndercover]

/azp run

[SnipUndercover]

@maddie480 It seems like the tas checks don't want to run? The action times out on waiting for the build to complete, even though it finished in 6 min.

[Wartori54]

Changes are good, but not too happy since if Steamworks.NET.dll was platform and arch independent all of these would not be required at all.
Patching Steamworks.NET.dll to be like that is something not really in the scope of this PR though. (But it should be looked into in the future.)

[maddie480]

@maddie480 It seems like the tas checks don't want to run? The action times out on waiting for the build to complete, even though it finished in 6 min.

it happens sometimes, Azure and GitHub Actions build "different merge commits", neither of which actually exist. GitHub builds ecc2f4d, Azure builds 11cb833, because ????

[maddie480]

(pushed an empty commit then force pushed to remove it, now both GitHub Actions and Azure Pipelines are working on commit a63dd5d so it should be fine)

[maddie480-bot]

The pull request was approved and entered the 3-day last-call window.
If no further reviews happen, it will end on Aug 24, 2025, 12:00 AM UTC, after which the pull request will be able to be merged.

[maddie480-bot]

The last-call window for this pull request ended. It can now be merged if no blockers were brought up.

[SnipUndercover]

(pushed an empty commit then force pushed to remove it, now both GitHub Actions and Azure Pipelines are working on commit a63dd5d so it should be fine)

Well for some reason the checks are still showing that they're canceled. Either GitHub is high or something's wrong, but I don't think this'll affect TASes by any means.
In any case, Let's Gamble, Try Merging.

[maddie480]

The checks on e0d57e1 pass if you go check the commit directly rather than the "Checks" tab, so I vote for "GitHub is high"