Windows: stop including <windows.h> from public OIIO headers

[aras-p]

Description

Including windows.h leads to a lot of possibly common names being "taken", mostly by preprocessor defines. Some of these are possible to turn off (like "max" and "min" by defining "NOMINMAX" before including <windows.h>). But many others are not possible to turn off, e.g. "near" and "far" just get defined to nothing, preventing from using variables named like that.

Additionally, includes have a cost, and while <windows.h>, being a C header does not have expensive language constructs that would slow down compilation a lot, it's still something close to 100k lines of preprocessed code to wade through.

Now, only the OIIO implementation .cpp files that actually need <windows.h> include it (all of them under "libutil").

There were two exceptions:

1. thread.h pause() implementation uses YieldProcessor() macro when on
   a Windows system. Replaced it with manually "re-implemented"
   things that YieldProcessor expands to. Right now made the
   implementation for all 4 platforms that Windows normally supports
   (x64, x86, arm, arm64); the latter two OIIO does not support though
   when on Windows so it's untested.
2. timer.h Timer::now() inline function used QueryPerformanceCounter
   and LARGE_INTEGER. These are quite hard to somehow "forward-declare"
   or similar, without resulting in duplicate type definitions. So on
   Windows I moved the now() function to be non-inline. A though for another
   day: maybe all of that could be replaced by C++ <chrono> instead.

Tests

Existing CI tests.

Checklist:

• I have read the contribution guidelines.
• If this is more extensive than a small change to existing code, I
  have previously submitted a Contributor License Agreement
  (individual, and if there is any way my
  employers might think my programming belongs to them, then also
  corporate).
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite
  (adding new test cases if necessary).
• My code follows the prevailing code style of this project.

[lgritz]

Yeah, the timer.h predates being able to depend on C++11 chrono. We'll want to benchmark to be sure that on all the platforms, chono is not higher overhead than when we're currently doing, but if it's good, I would have no objection to a future timer.h cleanup that bases it on chrono wherever possible.

[lgritz]

LGTM, I like getting windows.h out of the public headers.