fix: allow overriding status route response schemas

[Tony133]

Proposal:

The status route schema is built with:

schema: Object.assign({}, opts.exposeStatusRoute.routeSchemaOpts, { response: { 200, 500, 503 } })

so any response provided in routeSchemaOpts is silently discarded, and routeResponseSchemaOpts only affects the 200 properties. When the app uses a custom error handler that returns a payload with a different shape, the fields are stripped by the hard-coded 503 schema and /status replies with 503 {}.
There is currently no option to work around this.

Changes:

• routeSchemaOpts.response entries are merged over the defaults and take precedence (so 500/503, or any additional status code, can be customized).
• For 200, properties are merged instead of replaced, so status is always present as documented. routeResponseSchemaOpts keeps working as before.
• Defaults are unchanged when no response is provided.

A response key in routeSchemaOpts that was previously ignored is now applied. I believe this is what users passing it expected, but flagging it so you can decide whether this should go out as a patch or a minor.

Note:

• custom error handler + custom 503 schema returns the full payload
• custom 200 schema still includes status (and routeResponseSchemaOpts props)
• the exact test proposed in bug when setting custom error handler #206 happens to pass, because code and message are already part of the default 503 schema. The bug shows up as soon as the error handler uses any other field, e.g. { ok: false, reason }.

The two new tests fail on main and pass with this change. Coverage stays at 100%.

Fixes #206

[mcollina]

lgtm