Provides prebuilt libdave binaries.

[ha-ves]

@KubaZ2 Thanks for the library.

Here's some content I'd like to contribute.
It's providing Discord's libdave binaries via MSBuild to invoke the cmake build.
The cmake build is also highly customizable via MSBuild.

I'm making it a separate NuGet package, but let me know if you'd like other patterns.

This initial PR only tested for producing Windows .dll though.

There are also some Package References changes based on the alpha branch and authoring description changes for the packages...

Let me know your concerns.

---

Copilot PR Summary:

This pull request introduces significant improvements to the build system by integrating third-party C++ libraries (libdave and mlspp) as submodules and automating their native build process using MSBuild and CMake. It also updates .NET and key package dependencies to their latest versions, and enhances project metadata.

Third-party library integration and native build automation:

• Added libdave and mlspp as git submodules under NetCord/ThirdParty, and included a new project NetCord/ThirdParty/Libdave/Libdave.csproj for packaging prebuilt libdave binaries. (.gitmodules, NetCord.slnx, [1] [2] [3]
• Introduced MSBuild property and target files (Directory.Build.props, Directory.Build.targets, Libdave.build.props, Libdave.build.targets) to automate configuration, building, cleaning, and packaging of the libdave native library using CMake, with support for dependency injection and environment customization. [1] [2] [3] [4]
• Added logic for compatibility checks between MSBuild and CMake versions, and improved error handling and logging for native builds. [1] [2]

.NET and dependency updates:

• Updated the target framework from net9.0 to net10.0 and bumped several Microsoft.Extensions and System.Linq.AsyncEnumerable package versions from 9.x/10.0.0-rc to 10.0.1. [1] [2]

Project metadata and packaging enhancements:

• Added Authors metadata and improved package description in Directory.Build.props.
• Excluded third-party source files from the main NetCord project build and included new packaging rules for native binaries and build files. [1] [2] [3]

These changes lay the groundwork for robust native interop and easier maintenance of third-party dependencies in the NetCord ecosystem.

[KubaZ2]

I am not sure providing libdave via NuGet is the best idea. While it is kind of nice because providing native libraries just works in most cases, it isn't perfect.
First of all, it requires providing binaries for all major platforms to make sense, and even then, there will likely be some edge cases for less common OSes or architectures.
Another concern is static linking, which requires the binary to link against and I don't think it's possible to support it with such a package.
I think maybe just providing stand-alone binaries may be a better idea?

Btw, E2E encryption in NetCord is currently blocked by discord/libdave#13.

[ha-ves]

Note purposes.

TODOs

Package Structure

• Separate libdave binaries into individual RID-specific packages (e.g., NetCord.Native.libdave.win-x64, NetCord.Native.libdave.linux-x64)
• Create a main integration package that references and glues the platform-specific packages
• Keep separate from the main NetCord package to allow users to build their own binaries

Automation

• Set up automated builds for each supported runtime:
  • win-x64
  • win-x86
  • linux-x64
  • osx-x64
  • Notes:

  • OpenSSL 1.1.1 vs 3 differences in MSVC throwing warnings

• Add CI/CD pipeline for automated binary builds

MSBuild Integration

• Verify existing .props and .targets files work correctly:
  • Test dynamic library support (runtime copying)
  • Test static linking with NativeAOT (<NativeLibrary> + <DirectPInvoke>)
  • Verify platform detection logic across all RIDs
• Highly modular/customizable for external build

Documentation

• Document runtime package limitations (for now, using the E2EE feature is only on libdave-supported platforms)
• Add instructions for manual builds if users need unsupported platforms

Future Prospects

• Dave-protocol & MLS RFC 9420 fully implemented in .NET
• Expose Dave-protocol interfaces/functions for users to implement their own CODEC process/flow.