Return a struct from `gin`'s RegisterHandlers instead of an interface

[jazware]

This change provides an alternative to https://github.com/deepmap/oapi-codegen/pull/554 based on the discussions in https://github.com/deepmap/oapi-codegen/pull/530.

For setting up a Gin engine, we want to handle the IRouter interface when registering handlers, but as this only thinly wraps a *gin.GroupRouter, we can return a *gin.GroupRouter from the registration function.

We could refactor the RegisterHandlers and RegisterHandlersWithOptions to just take a *gin.GroupRouter to begin with, I'm not really sure what we gain by using the IRouter interface here. Does anyone have opinions on doing that?

[jazware]

I included autogeneration of new examples via go generate directives in the gin example folder that were missing which is likely what lead to this breaking change being merged without notice. If the changes make the generated code change in a breaking way, it will fail in make test now when it tries to build the example packages. make test runs after make generate so we should catch breaking changes this way.

[k0mmsussert0d]

Hi! Sorry to nudge you like this, but could you provide any estimate on when this is going to be merged? #485 poses major discrepancy when using this generator. I can see a solution had already been implemented in the past, but got reverted later due to inconsistencies with usage examples. If that's the only issue, would it be much of a trouble for you to align the documentation to match the actual API?

Afaik this project had some breaking changes in the release a week or two ago, perhaps now it's a good time to carry this change out.