Split AmbientLight into two

[Trashtalk217]

Objective

For resources-as-components (#19731), structs mustn't doubly derive both Component and Resource.

Solution

Split AmbientLight in two: AmbientLight (the resource) and AmbientLightOverride (the component).

Testing

I initially made two structs AmbientLightComponent and AmbientLightResource, and replaced every mention with the relevant one to ensure that I didn't confuse the two.

Notes

• I don't know if the names are correct. I kept the easiest name for the resource, as that's the one most often used.
• I haven't provided any conversion methods as there are already plans to replace the component variant with something else.

[mgi388]

Aren’t most games going to have many different 3D scenes and so the default ambient light is actually the special case here? I wonder if the special casing is backwards and we actually want DefaultAmbientLight and AmbientLight. Put another way, in my game I’m never going to use the resource one, I’m going to put an AmbientLight component on my different 3D cameras so it feels weird that with this PR I’d have to put an AmbientLightOverride component on those cameras—it’s not overriding anything either.

It also has nice parity with SpotLight and PointLight.

So would DefaultAmbientLight (resource) and AmbientLight (component) be a good option?

[Igor-dvr]

Related #18207

[Trashtalk217]

@mgi388 It could very well be a good option. I'm completely ambivalent about the names, as long as there's a consensus among the rendering people.

[alice-i-cecile]

These docs need updating.

[alice-i-cecile]

This needs to crosslink to the override.

[alice-i-cecile]

A few doc notes, and needs a migration guide. But I like the core idea: I think that this is less confusing.