GLTFLoader: Make KHR_materials_unlit able to be overridden

[0b5vr]

trafficstars

Will close #20709

What I did

• Replaced hardcoded behavior of KHR_materials_unlit with plugin system introduced in #19144 .
  • Current behavior completely ignores getMaterialType and extendMaterialParams of any plugin when KHR_materials_unlit exists in a material.
• GLTFLoader.register now registers the given plugin callback to the top of its plugin callback list instead of last.
  • Which means, GLTFLoader's plugin system now prioritizes user defined plugins than builtin ones.

Motivation

As I mentioned in #20709, I want to load our own custom glTF material using GLTFLoader. However, the glTF still have KHR_materials_unlit as a fallback, which is prioritized than any plugins registered. With these changes, I can override the behavior of KHR_materials_unlit.

Points need review

• GLTFMaterialsUnlitExtension.extendMaterialParams , does the "Removing material params" part look good?
• There still are parts that says materialType !== MeshBasicMaterial . I don't know how I can resolve this

[0b5vr]

Redone the commits against the latest dev , plus applied the changes also to examples/js/

[0b5vr]

ping @donmccurdy @takahirox , how do you think about it? See the "Points need review" section on the description.

[0b5vr]

Update! Thanks to #21207 I'm now able to remove KHR_materials_unlit in beforeRoot of the plugin that want to override the unlit, my demand is achieved. This PR still have a value I think though.

Ping @donmccurdy @takahirox

[donmccurdy]

Sorry for the delay – this looks good to me (after rebase) if @takahirox does not have any concerns!

[takahirox]

Ah sorry, I didn't notice the PR. Would you please resolve the conflicts? And then I will test and review.

[donmccurdy]

@0b5vr is this PR still something you're interested in having merged?

[Mugen87]

Closing. Seems the change is not required anymore.