feat(generator): RFC 9457 problem details are read as such, so errors show their detail instead of a JSON body

[giraffesyo]

What

A generated client reads an application/problem+json error as RFC 9457 problem details, whatever the operation's error schema declares.

• APIError records the response's ContentType.
• APIError.Problem() returns a *ProblemDetails (Type, Title, Status, Detail, Instance, and every other member in Extensions as raw JSON) for a problem body, and nil for any other media type or a body that doesn't parse as one.
• APIError.Error() renders the problem's detail, or its title when it has none, instead of the raw body.
• A typed error wrapper whose schema doesn't fit the problem (its parse fails, or the body lacks the wrapper's message field) now shows the problem's detail through APIError.Error() rather than JSON.
• ProblemDetails is a reserved identifier, so a schema with that name is renamed. README documents it.

Behavior for servers that don't send application/problem+json is unchanged.

Why

An API that answers with problem details, but whose spec still declares an older error schema for its operations, made generated clients print API error 422 ...: {"type":...}: the typed wrapper's parse failed on the problem's errors objects, and APIError only knew how to print the body. Code that wanted the problem's code had to re-parse Body itself.

Test

go test ./... (the new e2e test generates a client and checks detail and title rendering, members and extensions, that application/json bodies aren't parsed, malformed problems keep the body, both wrapper fallbacks, and a real round trip recording Content-Type with errors.Is(err, ErrNotFound) still true), go vet, gofmt, golangci-lint 0 issues.