Add optional decompiler hook for custom member display names in tree nodes

[geocine]

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.

[ElektroKill]

Hello,

This addition seems a lot like a hack fix rather than an actual solution. The API is currently inconsistent with the IDecompiler interface, which handles properties and types, while the rest is being done in NodeFormatter. This new api adds another interface, which is responsible for only methods, fields, and events. This only complicates the situation further. Instead of actually addressing the root problem. The ideal change would be to move all member formatting behavior to IDecompiler but that is a breaking change and will most likely be done in v7 together with all other major breaking changes.

The interface name IDecompilerMemberNameProvider is also quite confusing. The name implies the interface provides member names to the decompiler, which is not true. The interface provides member names to the NodeFormatter and also only provides the names for a subset of member types.

I'm also generally opposed to adding such hacky interfaces or APIs that are designed for one specific extension implementation.