refactor(log): return int from HandlerInterface::handle()

[Alexandros-Pallis]

Follow-up to #10560 , implementing the approach agreed there for 4.8.

Problem

Logger::log() stops running handlers when one returns false from handle(). The built-in handlers (FileHandler,
ErrorlogHandler) return false when a write fails, so one failing handler (e.g. FileHandler with bad permissions on
the log directory) silently prevents every handler after it from logging. A configured ErrorlogHandler fallback never
runs and the log entry is lost.
false was doing two jobs: "the write failed" and "stop the chain". A handler had no way to report one without
triggering the other.

Change

HandlerInterface::handle() now returns int instead of bool, as suggested by @paulbalandan:

• HandlerInterface::RESULT_CONTINUE (1): the remaining handlers run.
• HandlerInterface::RESULT_STOP (2): the chain stops.

Logger::log() breaks only on RESULT_STOP. Any other value continues.

The built-in handlers (FileHandler, ErrorlogHandler, ChromeLoggerHandler) and the test TestHandler always return
RESULT_CONTINUE, including when a write fails. That fixes the original problem.

Behavior changes

• A FileHandler that cannot write no longer stops later handlers. On develop it did.
• The built-in handlers no longer expose write failure through their return value. Nothing in the framework consumed it
  apart from the chain-stopping break, but code calling handle() directly and checking the result would no longer see
  failures.

Breaking change

Custom log handlers that override handle() must change the return type from bool to int and return the new constants (true -> RESULT_CONTINUE, false -> RESULT_STOP). A handler still declaring : bool is incompatible with the interface and causes a fatal error when the class loads. Migration steps are in upgrade_480.rst.

Tests

• LoggerTest: a handler returning RESULT_CONTINUE lets the next handler run; one returning RESULT_STOP prevents it.
• FileHandlerTest: a file that cannot be opened returns RESULT_CONTINUE.
• Existing handler tests now assert RESULT_CONTINUE instead of true.
• tests/system/Log passes (61 tests), also in random order.

Docs

• upgrade_480.rst: return type change, constants, before/after example.
• v4.8.0.rst: Interface Changes entry and a Changes entry for the FileHandler behavior.
• general/logging.rst: note on handler order and return values.

Checklist

• I have read the CONTRIBUTING guide
• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• This PR is on a custom branch and not develop

[neznaika0]

It looks logical, but now we practically have no option to stop the handler - result is always returned to continue processing.

Perhaps, after these changes, stopping is not required at all, in which case, what’s the point of the new constants?