feat: add Echo v5 adapter

[oscarbc96]

Summary

• Adds a new echov5openapi adapter to support Echo v5, which introduced several breaking changes from v4 (pointer *echo.Context, RouteInfo return types, log/slog logger, etc.)
• The existing echoopenapi adapter continues to work for Echo v4 users
• Includes full test coverage (657+ lines of tests), a working example, and comprehensive README with migration guide

What's included

• adapter/echov5openapi/ — full adapter implementation:
  • router.go — Router/Generator with all HTTP method handlers, route groups, middleware, static file serving, and OpenAPI doc endpoints
  • route.go — Route wrapper bridging Echo v5 RouteInfo with spec.Route
  • types.go — Generator, Router, and Route interfaces matching the Echo v5 API
  • router_test.go — comprehensive tests covering all HTTP methods, groups, middleware, schema generation, validation, and edge cases
  • examples/basic/ — working example with auth middleware
  • README.MD — documentation with quick start, migration guide from v4, and API reference
• Updated adapter/README.md to list both Echo v4 and Echo v5 adapters
• Updated go.work to include the new module

Echo v5 breaking changes handled

Change	v4	v5
Context	echo.Context (interface)	*echo.Context (pointer)
Route return	*echo.Route	echo.RouteInfo (struct)
Route fields	.Method, .Path, .Name methods	.Method, .Path, .Name fields
Static methods	Static(prefix, root)	Static(prefix, root, ...middleware)
Logger	Custom echo.Logger	log/slog

How to test

This was developed using Claude Code. To test before this is merged, you can use Go module replacements in your go.mod:

replace github.com/oaswrap/spec => github.com/oscarbc96/spec v0.0.0-20260301171053-28d75808da62

replace github.com/oaswrap/spec/adapter/echov5openapi => github.com/oscarbc96/spec/adapter/echov5openapi v0.0.0-20260301171053-28d75808da62

🤖 Generated with Claude Code

[oscarbc96]

Hey @adaosantos @akfaiz — this PR adds an Echo v5 adapter following the same pattern as the existing adapters (echoopenapi for v4, echov5openapi for v5).

However, I noticed your discussion in #42 about adapter versioning strategy and the Datadog-style approach (echo.v4/, echo.v5/). Right now the naming is asymmetric — echoopenapi (v4) vs echov5openapi (v5) — which could get inconsistent as more framework versions are added.

How do you think we should handle this here? A few options:

1. Keep as-is (echov5openapi) and address naming consistency later across all adapters
2. Rename v4 to echov4openapi for symmetry with this PR
3. Adopt directory-based versioning (e.g., echoopenapi/v4, echoopenapi/v5) as discussed in feat(adapters): reorganize Fiber adapters into version-specific directories #42

Would love to align on this before merging. What's your preference?