fix(hero): run result handlers when handler returns nil (#2534)

[rifkir23]

Description

A handler registered through the hero/MVC container that returns a nil value does not run the configured result handler chain. UseResultHandler handlers are silently skipped for nil returns:

app.ConfigureContainer().UseResultHandler(func(next iris.ResultHandler) iris.ResultHandler {
    return func(ctx iris.Context, v interface{}) error {
        // never called when the controller returns nil
        return next(ctx, v)
    }
})

func (c *CustomController) Get() any { return nil }

Fixes #2534

Root cause

In hero/func_result.go, dispatchCommon only invokes the result handler chain when the value is non-nil:

if v != nil {
    return handler(ctx, v)
}
// v == nil: flush headers/content, handler chain skipped

So when a handler returns nil, custom stays nil and the UseResultHandler chain never runs.

Fix

When the container has custom result handlers registered, run the handler chain even for a nil value — a nil return is a legitimate case a custom handler may want to observe or replace. Behavior without custom handlers is unchanged: the default handler is still not invoked on nil, so nil returns keep flushing headers/content exactly as before. The flag is threaded from the call site (len(c.resultHandlers) > 0); Response.Dispatch passes false.

Tests

Added TestContainerUseResultHandlerOnNil: a handler returning nil with a registered UseResultHandler now runs the handler (which replaces the nil result), and the response reflects the replacement. Verified it fails before the change ("result handler was not called for a nil return value") and passes after. Full hero suite passes; gofmt and go vet clean.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}