Add support for NodeMaterial in TilesFadePlugin

[shotamatsuda]

This PR adds preliminary support for NodeMaterial in TilesFadePlugin. I consider this preliminary because it doesn't support BatchedMesh, as I have not been able to use BatchedMeshPlugin with WebGPURenderer yet.

A possible incompatibility is that it will not work if the user is using importmaps and doesn't have a route to three/tsl.

An example page was added for demonstration purposes, but it's mostly a duplicate. It would be ideal to add the ability to switch the renderer in fadingTiles.html. I'll be happy to remove it, or to work on it if this PR is legitimate.

[gkjohnson]

Thanks @shotamatsuda! And sorry for the delay in reply.

I suppose some (all?) of my concerns from mrdoob/three.js#30185 are finally coming to pass, so I'm trying to decide what to do here 😅 It's also exposing a few other issues I wasn't expecting, like the custom ring shader for EnvironmentControls anchor not rendering and logging an error with WebGPURenderer. Generally I want to support WebGPU more directly but unfortunately with the way three.js is handling things that will seem to mean maintaining two copies of every shader in the project since most if not all of my other users and clients are on WebGLRenderer and complicate the APIs (no one else has complained about WebGPU support yet).

cc @mrdoob are there any more concrete plans for how to more gracefully handle the WebGL -> WebGPU material transition? This is exactly the kind of issue I anticipated running in to and trying to avoid. These types of issues are going to make maintaining the project much more difficult and much less enjoyable. To lay it all out:

• All custom materials must be written and maintained twice in order to support WebGL & WebGPU.
• Code must contain an internal switch to detect node materials but even then it's not fool-proof since users can assign non-node materials and have them work gracefully in WebGPURenderer (the strategy used in this PR is not resilient to this case). So the only robust option is to require users to pass a "webGPU: true" option into everything that needs to know the target rendering system. The solution in this PR is to require the user to manually manage and replace all loaded materials because there's otherwise no way to gracefully support both renderers.
• TSL code will be imported into webgl projects that do not need it and vice-versa for webgpu projects importing shader lib code, unnecessarily inflating project sizes.
• The three.js project is encouraging users to replace the "three" import with the "three/webgpu" variant which means any internal dependency that expects "three" to export ShaderMaterial etc will break if users follow the guidance implied by the official three.js examples (see this fiddle from three.js bug reports, and the official webgpu example imports).

[shotamatsuda]

Thanks for sparing your time on this PR!

I'm perfectly fine with you and Three.js taking time to make the best decision, especially since you haven't had any requests for WebGPU support from your clients. Support for NodeMaterial in TilesFadePlugin can be implemented in user code, thanks to the plugin architecture. As to the pivot mesh, which I had not noticed, I agree that having two copies of shaders is redundant and makes it harder to maintain, and it makes sense to wait for Three.js to support NodeMaterial in WebGLRenderer.