Gate the native engine on the host OS, not the active build target

[MonoFinity]

The problem

UWB picks its native engine off the Unity active build target, but the engine is a native child process of the running Unity process — so in the Editor, the platform that matters is the one the Editor itself is running on.

Because the selection is keyed on UNITY_STANDALONE_* alone, a Windows Editor whose active build target is WebGL, Android or a console compiles:

• WebBrowserUtils.GetRunningPlatform() down to throw new PlatformNotSupportedException(), and
• EngineProcess's constructor down to nothing, leaving processHandle null so every member forwarding to it throws a NullReferenceException.

The practical effect is that UWB cannot be used in the Editor at all by any project that is not currently targeting Standalone. There is no runtime override for it — it's a compile-time gate, so no Engine subclass hook or asmdef arrangement works around it. Switching the build target to Standalone just to preview a webview is disruptive on a large project (it forces an asset re-import and invalidates the platform's script defines).

The change

Widen each gate to UNITY_STANDALONE_X || UNITY_EDITOR_X in the six places that select or compile the per-platform process wrapper:

File	Gate
Helper/WebBrowserUtils.cs	GetRunningPlatform()
Core/Engines/EngineProcess.cs	ctor processHandle selection
Core/Engines/EngineConfiguration.cs	GetEngineExecutableName() — a Windows Editor must still look for the .exe
Core/Engines/Process/WindowProcess.cs	file guard
Core/Engines/Process/LinuxProcess.cs	file guard
Core/Engines/Process/MacOsProcess.cs	file guard

Player builds are unaffected

This only widens what compiles inside the Editor. A Standalone player defines UNITY_STANDALONE_X but not UNITY_EDITOR_X; a WebGL/Android player defines neither. Both keep the existing behaviour byte-for-byte.

Notes

• Verified against master (f49743d).
• We've been running this patch in a vendored copy of 2.2.8 for production Editor work on Windows, hosting a CEF-rendered React UI in the Game View with the build target set to WebGL.
• Sent as a separate PR from Bound the TCP client's connect timeout instead of int.MaxValue #440 — the two are independent and either can be taken without the other.

[Voltstro]

A more better way would be to check the editor platform first, then check the target platform only if the build is not an editor. That way if someone is using Linux editor with the target set to Windows, it will start the Linux process in editor.

#if UNITY_EDITOR_WIN || (!UNITY_EDITOR && UNITY_STANDALONE_WIN)
            processHandle = new WindowProcess();
#elif UNITY_EDITOR_LINUX || (!UNITY_EDITOR && UNITY_STANDALONE_LINUX)
            processHandle = new LinuxProcess(logger);
#elif UNITY_EDITOR_OSX || (!UNITY_EDITOR && UNITY_STANDALONE_OSX)
            processHandle = new MacOsProcess();
#endif

[Voltstro]

Same as comment on EngineProcess.

[Voltstro]

Same as comment on EngineProcess.