### Summary
* Swagger: remove `sortOrder` query parameter from several endpoints in which it didn't make sense.
* Swagger: remove query params `page` and `pageSize` from endpoints that return a single object.
* Sort the output of `GET /api/v1/governor/config` by ascending id.
* Refactor: remove duplicated code, format code for readability.
The API's swagger documentation exposes a route
`GET /api/v1/governor/max_available/:chain`,
but instead it should be
`GET /api/v1/governor/notional/max_available/:chain`.
### Summary
Changes to `GET /api/v1/governor/limit`:
* Fix the behavior of the parameters `page` and `pageSize` (which previously were being ignored).
* When no results are found, return an HTTP status code of 200 and set the response to an empty array.
* Remove the `sortOrder` query parameter.
The rationale for removing the `sortOrder` parameter is that sorting chains by ascending/descending chain ID doesn't seem to be a useful operation.
### Summary
In some cases, the query parameters for a MongoDB aggregation pipeline were not being initialized.
This led to errors in `GET /api/v1/vaas/{chain}/{emitter}/{seq}`.
Other endpoints could also have been affected.
Previously, when calling `GET /api/v1/governor/enqueued_vaas`, it returned a status code of 404 when there were no enqueued VAAs.
Now, the endpoint returns a status code of 200, and the response body contains an empty array.
### Summary
* On all endpoints, fix the behavior of the `page` parameter (which was previously being ignored).
* On `GET /api/v1/vaas`, fix the behavior of the `sortBy` parameter (which wasn't working when `parsedPayload=true`).
* For all endpoints, validate the query parameters `page`, `pageNumber` and `sortOrder`.
* Return descriptive errors when pagination-related parameters happen to be invalid (`page`, `pageSize`, `sortOrder`).
* Validate guardian addresses in query params.
### Testing plan
All parameters involved were manually tested.
### Summary
Before this PR, when validating a VAA, we were always using the latest guardian set index to verify the signatures.
With this PR, we're making the signature verification against `vaa.guardianSetIndex` instead.
Context: https://github.com/wormhole-foundation/wormhole-explorer/issues/104
### Testing plan
* Added unit test cases
* Also tested manually
### Summary
Split `/v1` and `/api/v1` controllers into different packages (respectively `api/routes/guardian` and `api/routes/wormscan`).
Still need to move services/repositories/models according to the new package layout.
### Summary
Updating from swaggo v1.8.9 to v1.8.10 caused issues with the generated swagger file.
The issue was solved by moving the handler for `GET /swagger.json` outside the `/doc` directory.
* add vaaId and txHash relation in vaaIdTxHash collection
* add txHash in vaas collection
* add txHash in response vaa and as filter in find vaas endpoints