Streamline project setup

[mmjr-x]

I am making an effort to streamline the project's setup a bit

Finished:

• Nuget bepinex source is now automatically included
• Implemented setting the game directory via auto-generated DevEnv.targets file
• Cleaned up direct assembly references to transient nuget dependencies
• Integrated protobuf into the project via vcpkg export of a local nuget package and added instructions on how to update it to the readme
• Add part that project should be git submodule initted (else enet does not get installed) to the readme
• .proto files of the WorldsAdriftRebornCoreSdk are now compiled as part of the build process
• Converted WorldsAdriftReborn to use PackageReference instead of package.config and removed direct reference to UnityEngine
• Fleshed out solution configurations for Any CPU, x64 and x86 (x86 currently does not compile the WorldsAdriftRebornCoreSdk project)
• Modernize projects using https://github.com/hvanbakel/CsprojToVs2017
• WorldsAdriftReborn csproject will now direclty build its output to the \BepInEx\plugins\WorldsAdriftReborn\ folder if the project if the DevEnv.targets was set up correctly
• Switched WorldsAdriftRebornCoreSdk over to use the static-md version of protobuf (static linking is supposedly better for protobuf ( https://github.com/protocolbuffers/protobuf/blob/main/cmake/README.md#dlls-vs-static-linking ) also the vcpkg exported nuget packages supports dynamic, static and static-md build types so we can easily switch in the future) Updated the protobuf update section and clarified different linking mode options for the protobuf library in the readme.
• Now using the https://www.nuget.org/packages/WorldsAdriftReborn-protobuf-x64-windows-static-md/ for the protobuf package instead of a local version and updated the readme accordingly
• CoreSdkDll is now swapped out with our variant using mono_dllmap_insert (eliminates the need to manually overwrite it and touch the game files)
• Made WorldsAdriftReborn and WorldsAdriftRebornGameServer dependant on WorldsAdriftRebornCoreSdk project and have the output automatically included with the outputs of both projects (this results in a fully automated setup which requires no extra copy steps)
• Building the WordsAdriftReborn project now gives you an error if the referenced Assembly-CSharp game assembly does not have the correct hash (since at that point you are most likely targetting the wrong game version)
• Add graceful error popup when starting the game and the replacement CoreSdkDll can not be found
• Add graceful error popup when starting the game and game version is incorrect
• Make launch configuration that runs both server and game (you need to launch Worlds Adrift in non debug mode, and can launch multiple projects using the launch configuration editor, sadly no way to auto include the configuration for this)
• Updated README.md with relevant information:
  • Added that VS 2022 as a requirement (some dot net 6.0 stuff is used which is not supported by VS 2019)
  • Clarified that the steam latest version is not the correct version (and why)
  • Added part that project should be set to x64 before building
  • Added other relevant information
  • Removed outdated information

TODO:

• Investigate possibly using doorstop or bepinex detouring to inject the CoreSdkDll instead of overwriting it directly (that way the game files do not have to be touched directly) (Tested preload patchers, however had no effect since the CoreSdkDll is only used via DllImport in the Improbable.Worker.Internal of the game, found different method of swapping it out and utilized that)
• Investigate if it is worth switching to PackageReference instead of package.config (only the WorldsAdriftRebornCoreSdk is not switched over yet, however only the latest version of visual studio supports this for C++ projects so we might keep it like this for now)
• Investigate making and using stubbed and publicized game assemblies using BepInEx's workflow ( https://github.com/BepInEx/BepInEx.NuGetUpload.Service/wiki https://github.com/BepInEx/BepInEx.NuGetUpload.Service/issues/new?template=key_request.yaml and https://nuget-upload.bepinex.dev/ )
• Probably remove the x86 build target form the solution (I don't know if this will ever be used)

This is my rough outline, however thoughts and suggestions are always welcome! :)

[TheSpookyCat]

While I understand the reasons for doing so, making VS22 a requirement for a game released 5 years ago is a bit of a joke imho

[mmjr-x]

While I understand the reasons for doing so, making VS22 a requirement for a game released 5 years ago is a bit of a joke imho

Haha I feel you, sadly it was a requirement even before this PR ;) so I just clarified it in the readme.