This is intended as a generic extensibility fix for custom decompilers, not a behavior change for built in dnSpy decompilers

Problem

Today, dnSpy tree labels for some member kinds still use raw metadata names directly in NodeFormatter instead of asking the active decompiler for a display name.

That means custom decompilers or decompiler decorators can change names in decompiled output, but the document tree on the left can still show the original metadata names. The result is inconsistent UI between the tree and the decompiled text.

Solution

This PR adds a new optional interface:

• IDecompilerMemberNameProvider

and updates NodeFormatter to use it for member kinds where the tree currently hardcodes metadata names:

• methods
• fields
• events

I wanted to keep the change generic and non invasive:

• no behavior change for existing decompilers
• no dependency on any specific extension or renaming system
• custom decompilers can opt in only if they need custom tree labels
• avoids pushing plugin specific logic into dnSpy core

Impact

For built in dnSpy behavior, this should be a noop unless a decompiler explicitly implements the new interface.

For custom decompilers/decorators, this makes it possible to keep the document tree labels consistent with the names shown in decompiled output.

This is also useful for plugin development where decompiler behavior is extended outside upstream dnSpy. In my case, this helps sourcemap name remapping stay consistent between the decompiled text and the document tree without carrying a larger fork specific patch in dnSpy core.