Refactor normalization handling and add ApplyPostNormalizeTransform

[struckchure]

Problem / Use case

I have 3 types of the same struct name as a response model, it became a problem quickly, cause they were overriding each other (in order, i think).

// one/type.go
type Response struct { x string }

// two/type.go
type Response struct { y string }

// three/type.go
type Response struct { z string }

With the current implement, you get just 1 Response and the rest is just gone.

Proposed Solution

func last[T any](slice []T, n int) []T {
	if n <= 0 {
		return nil
	}
	if len(slice) < n {
		return slice
	}
	return slice[len(slice)-n:]
}

opts = append(opts, func(a *rest.API) {
	a.ApplyPostNormalizeTransform = func(normalized string) string {
		normalized = strings.Join(last(strings.Split(normalized, "_"), 2), "_")
		return lo.PascalCase(normalized)
	}
})
api = rest.NewAPI(name, opts...)

now, i'll have OneReponse, TwoResponse and ThreeResponse

Implementation Details

This pull request introduces a new hook to allow post-processing of normalized type names in the API schema generation logic. The main change is the addition of a configurable function that can be used to further transform normalized names after the default normalization logic has been applied.

Enhancements to type name normalization:

• Added an ApplyPostNormalizeTransform function field to the API struct in api.go, allowing custom post-processing of normalized type names.
• Updated the normalizeTypeName method in schema.go to call ApplyPostNormalizeTransform if it is set, enabling additional transformation of the normalized string before returning it.

[struckchure]

Maybe it might be worth considering as part of rest's implementation or just leave it as a mod-able thing, either works. I just made a quick fix for my project, then i wanted to share the update here. Let me know what you think.