Restore dirty list for BaseMaterial3D but don't use it on resource loader.

[DarioSamo]

Fixes #99576.

Visual updates for Material3D broke in general as I added the ability for materials and shaders to defer the updates according to what @reduz outlined for pipeline pre-compilation.

The dirty list is a bit of a hacky solution to make sure the updates reach in time to the materials on the scene, but we don't have a much better way to do it for architectural reasons. There's sadly no way for these minor material modifications to properly notify the scene geometry that it should request an update again by querying the RID of the Material or the shader.

For the sake of keeping the improvement I added for deferring the shader updates, as it's a huge improvement that allows shaders to be compiled by the resource loader, I used a change that Pedro recently did where it'll skip on adding the material to the dirty list if it's found to be within a resource loader.

While the logic might seem similar at first glance, the big difference is that it does not defer the call using the deferred mechanism but rather it allows the thread that requires the material to load it when necessary.

Requesting a review from @RandomShaper just to make sure this change makes sense.

We should make sure this doesn't break any existing logic with background loaders (demo projects that use background threads on loading screens) and that it still works as intended.

[DarioSamo]

I talked with @RandomShaper and I implemented his suggestion of not relying on the getter behavior and going for the new approach that the Material constructor uses.

However, pipeline pre-compilation on meshes on some of my tested scenes have gone down about 10%, resulting in surface pre-compilations instead. It seems the logic for handling the material/shader dependencies is not as exact as it might sound. I've not determined the cause of this reduction yet, and while it's a very small impact, it probably warrants another look to make sure dependencies are sorted out properly for materials.

[DarioSamo]

I've restored the original approach the PR takes as it just improves the amount of pipeline pre-compilation in general.

[RandomShaper]

This is good enough!

However, I may make a follow-up that restores a bit more of the original approach because the lack of pipelines may be rooted elsewhere. I'm testing my hypothesis. Until then...

[Repiteo]

Thanks!