[3.0] Improve handling of nested struct names and affixes

[Exanite]

Summary of the PR

I also call this the "referenced affix" PR due to the system introduced to the problem below.

The problem

Nested struct names are an edge case in the name affix system because they have the following format:

NestedStructName = ParentBaseName + ParentSuffix + FieldBaseName + FieldSuffix

Currently, nested struct names are generated by directly combining the full parent type name with the full field name.
This leads to issues where the ParentSuffix is not handled correctly.

For example, PerformanceCounterDescriptionArmName should be PerformanceCounterDescriptionARMName.

The solution

This PR adds a "referenced affix" system where name affixes can reference the names of other symbols.
This is based on the observation that these names are compound names where part of the name makes use of a name of another symbol.

For example, PerformanceCounterDescriptionARMName is annotated as the following:

[NativeName("_name_e__FixedBuffer")]
[InlineArray(256)]
[NameAffix("Prefix", "NestedStructParent", nameof(PerformanceCounterDescriptionARM))]
[SupportedApiProfile("vulkan")]
public partial struct PerformanceCounterDescriptionARMName
{
    // ...
}

This allows PrettifyNames to use the final value of the referenced name (PerformanceCounterDescriptionARM) as the final value for the affix. This means all changes are automatically synchronized between the two names (caveat: name overrides currently do not work due to an edge case interaction; I plan to rework the system to cleanly handle this case).

Related issues, Discord discussions, or proposals

Original discussion: https://discord.com/channels/521092042781229087/587346162802229298/1460017726813900975

Further Comments

Tasks

• Improve handling of nested struct names
  • Eg: PerformanceCounterDescriptionArmName should be PerformanceCounterDescriptionARMName
  • Original conversation here: https://discord.com/channels/521092042781229087/587346162802229298/1460017726813900975
• Consider splitting ExtractNestedTyping and TransformHandles into a new set of Extract- mods.
  • This this mainly for maintainability for ExtractNestedTyping, but for TransformHandles it is useful for AddApiProfiles to be executed after all types are extracted, but not yet transformed.
  • Split TransformHandles into TransformHandles and ExtractHandles
  • Also split up ExtractNestedTyping
    • Note: Currently holding off on this since this has performance implications.
• Address INameTrimmer.Order/Version issue (we don't want magic numbers) and consider removing INameTrimmer entirely.
• Rename INameTrimmer to INameProcessor and update names where relevant
  • Do a second documentation pass to ensure that all docs and variable names are updated
• Regenerate all bindings using Windows
• Update OpenAL name overrides
  • About half of the overrides can now be removed since they are now handled automatically by the name affix system.
  • Edit: Hmm, the override system actually conflicts here. The current name processing system can't see overridden names since they get removed from the name container at the very start.
    • This means that overrides are not properly taken into account by referenced affixes.
    • Eg: ALBUFFERCALLBACKTYPESOFTDelegate uses the native name of BufferCallbackSOFT (native name ALBUFFERCALLBACKTYPESOFT) as a prefix. This should allow PrettifyNames to replace ALBUFFERCALLBACKTYPESOFT in ALBUFFERCALLBACKTYPESOFTDelegate with BufferCallbackSOFT, thus resulting in BufferCallbackSOFTDelegate. However, this is not currently the case because the name lookup fails.
    • Somehow handle the referenced affix + name override edge case. Easy way out is to either manually override or have the name processor look at the name overrides dictionary, but both are hacky.
    • Decision: Handle this by preferring the value from the current name container and falling back to the "final" names dictionary (which needs to be exposed to the processors).
• Add unit tests
  • Referenced affix cycle detection
  • Referenced affix missing reference
  • Referenced affix exists, but is in different container
  • Referenced affix success case