fix(win): Embed manifest in OIIO .exes to enable long path handling

[nrusch]

Description

Adds an embedded manifest to OIIO's generated executables on Windows, which enables "long path" awareness.

This is done via a "resource" file, with the manifest resource ID specified. From what I've read, this is more broadly compatible with e.g. non-MSVC build toolchains like MinGW.

The manifest file was created by building OIIO from main, extracting the manifest from the resulting oiiotool (using the mt tool), and manually adding in the XML snippet from https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#application-manifest-updates-to-declare-long-path-capability.

Fixes #5064

Tests

No new tests added, but I have confirmed that built executables seem to "just work" with long paths after applying this patch, where they are unable to open the path prior to patching.

The one executable that I have not tested is iv. The only reason I'm more curious about it than others is that it is a GUI executable, so I'm not sure if its default

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested somewhere in the
  testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: nrusch / name: Nathan Rusch (1e67550)

[nrusch]

This is something I don't have a strong instinct for. The manifest resource ID isn't going to change, and this value hardcoding seems to be fairly commonplace from what I've found. I opted to avoid an #include here to start just because I don't know if that would have any other implications.

[lgritz]

Need a DCO sign-off on the commit.

Can you add something to the testsuite that verifies that this allows the long filenames so we will know if there is any regression?

[nrusch]

DCO should be fixed. I'll look at adding a test for this as soon as I can.