[vbs-enclave-tooling-codegen] Update to 0.1.2-prerelease.250820.1

[bbonaby]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

I updated the port to use the new NuGet package in our nuget feed instead of restoring the solution file via nuget restore.

asdf

[dg0yt]

Nitpick, do as you like.

Suggested change

	vcpkg_copy_tools(TOOL_NAMES edlcodegen SEARCH_DIR "${PACKAGE_PATH}/bin" AUTO_CLEAN)
	vcpkg_copy_tools(TOOL_NAMES edlcodegen SEARCH_DIR "${PACKAGE_PATH}/bin")

PACKAGE_PATH is the extracted binary blob. AUTO_CLEAN isn't needed, and it breaks editable builds. (But who would edit a non-source package.)

[JavierMatosD]

@bbonaby can you explain the motivation for this change?

[bbonaby]

@JavierMatosD The motivation here is that there is really no need for us to be building the codegen tool from source here. Vbs enclaves themselves only run on x64 and arm64. Since we already ship the tool via nuget with these in it, there isn't a special need to rebuild it.

As an aside, building from source also causes issues in different build pipelines due to its reliance on https://vcpkg.io/en/package/vcpkg-pkgconfig-get-modules.html. A good example is in OSClient, pkgconfig causes build warnings for msvc (due to usage of deprecated apis) in their pipeline which causes the build to fail. To avoid this and anything in the future, since we simply want to distribute the tool here for folks that can't use nuget e.g the OS repo, to me the better way would be to just use the prepackaged nuget.