proposal: Optional Material Override Specification for VRM1

[miramocha]

I'm proposing an optional multi-engine material/shader override specs that will work similar to how VRMC_springBone_extended_collider currently works. It will replace/extend mtoon/khr material when shader is applicable and fallback to mtoon otherwise.

Current working implementation/proof of concept:
https://github.com/miramocha/Extended-VRM-Specs/blob/main/examples/mtoonxt-liltoon-override-warudo.md

In the example implementation page, there is also MToonXT specs but please ignore it for the time being when reviewing this PR as it is not in scope.

Note that on the page/repo the extension name prefix is VRMXT_ to prevent collision with current official source, and we are replacing it with VRMC_ in this proposal.

I'll be happy to discuss, walkthrough, and take any suggestion into consideration, thank you.

[0b5vr]

Thank you for the proposal and the proof of concept.

We recognize the usefulness of storing engine-specific material descriptions in glTF.
However, the VRM Consortium does not plan to standardize engine-specific material or shader properties, since our mission is to establish a platform-independent standard for 3D characters.

For an official VRMC material extension, we would need to define portable semantics and expected rendering behavior that can be implemented consistently across different engines.
For example, simply storing a set of lilToon property names would not provide enough information for non-Unity implementations to reproduce the appearance intended by the artist.
This proposal is conceptually similar to the shader-dependent materialProperties mechanism in VRM 0.x.
In VRM 1.0, we moved away from serializing implementation-specific material properties and instead defined MToon properties in terms of portable rendering semantics.
We do not intend to reintroduce an official mechanism for serializing arbitrary engine-specific material properties.

Such extensions can instead be developed and maintained independently as a third-party extension, without requiring standardization by the VRM Consortium.
As a personal recommendation, if you continue developing this specification, I suggest defining clear conventions for its namespace and semantic vocabulary to avoid confusion within the community.