FR: alternative EnumCache and extensions to De/Humanize enums

[KillyMXI]

My understanding is that there is currently DehumanizeTo extension that is intended to work exactly in reverse of Humanize.
At the same time, it is not necessarily what I expect as a user of the library.

public enum ExampleEnum
{
    [Display(Name = "The foo", Description = "something about what effect Foo makes")]
    Foo,
    [Display(Name = "The bar", Description = "something about what effect Bar makes")]
    Bar,
}

I don't expect to parse input string in the format of description.
I expect the input script to be the best approximation of a parseable name.

And so, I think the reasonable string-to-value dictionary may consist of normalized strings taken from ToString value, display name, description, whatever else can be located in the attributes...

Current implementation prioritizes Description and takes only one string:

Humanizer/src/Humanizer/EnumCache.cs

Lines 64 to 73 in 3d80235

	static bool TryGetDescription(MemberInfo member, [NotNullWhen(true)] out string? description)
	{
	var displayAttribute = member.GetCustomAttribute<DisplayAttribute>();
	if (displayAttribute != null)
	{
	description = displayAttribute.GetDescription() ?? displayAttribute.GetName();
	return description != null;
	}

I don't understand the utility of this. It breaks valid usage scenarios.
And it seems that for a workaround I have to reimplement a custom dehumanizer from scratch.

This is probably related to #700.

By extension, if I need the Humanize function - I will face the same issue - I don't necessarily need the description - I may prefer to:

• use Name attribute if it is available;
• or humanize ToString value.

To resolve both problems, alternative implementation to current EnumCache and extensions might be conceived, probably in parallel to the existing one to avoid breaking change.
It may be not exactly what I expect it to be to solve each direction issue, but I'd like this to be a started for a discussion at least.

Seems like Humanizer might've been around before System.ComponentModel.DataAnnotations.DisplayAttribute and is still based on more limited assumptions.

From DisplayAttribute.cs:

Property	Intended purpose
Name	The name is generally used as the field label for a UI element bound to the member bearing this attribute.
ShortName	The short name is generally used as the grid column label for a UI element bound to the member bearing this attribute.
Description	Description is generally used as a tool tip or description a UI element bound to the member bearing this attribute.
Prompt	A prompt is generally used as a prompt or watermark for a UI element bound to the member bearing this attribute.
GroupName	A group name is used for grouping fields into the UI.

Of those, I only really see Name and ShortName as well suitable for de/humanization.