feat(response): remove class constraints to support value types

[davidkallesen]

Summary

The EndpointResponse generic types and helper methods (InvalidContentAccessException, CastContent) had where T : class
constraints that prevented generated client code from using value types like Guid, int, or DateTime as response content types. This
caused CS0452 compilation errors in projects using the source generator when an API returns a value type. This PR removes all
unnecessary class constraints across the response type hierarchy and builder interfaces.

Changes

💥 Breaking Changes

• Remove where TSuccess : class constraint from EndpointResponse
• Remove where TSuccess : class and where TError : class constraints from EndpointResponse<TSuccess, TError>
• Remove class constraints from IMessageResponseBuilder.BuildResponseAsync generic methods
• Remove class constraints from MessageResponseBuilder.BuildResponseAsync generic methods

🐛 Fixes

• Remove where TExpected : class from InvalidContentAccessException — only uses typeof(TExpected).Name, no reference
  type needed
• Update CastContent to use is pattern matching instead of as operator, enabling value type unboxing

✨ Features

• EndpointResponse and EndpointResponse<TSuccess, TError> now accept value types (Guid, int, bool, DateTime, etc.)

📝 Documentation

• Update README to reflect removed class constraints on IMessageResponseBuilder method signatures

✅ Tests

• Add value type test coverage: InvalidContentAccessException, EndpointResponse success/failure/wrong-type scenarios

Notes

This is a source-compatible relaxation of constraints — all existing code using reference types continues to work unchanged. For
value type TSuccess, SuccessContent returns default(TSuccess) (e.g., Guid.Empty) on failure rather than null, since unconstrained
T? is a nullable annotation only and does not produce Nullable for value types.