Fix callTracer missing revertReason and nested calls for reverted transactions

[usmansaleem]

PR description

This PR fixes two critical issues in Besu's callTracer implementation that caused incompatibility with Geth when tracing reverted transactions.

Issue 1: Missing revertReason field for reverted transactions

Problem:
When a transaction reverted with an Error(string) message, Besu's callTracer output included the ABI-encoded revert data in the output field but was
missing the decoded revertReason field that Geth provides.

Root Cause:
CallTracerErrorHandler was not decoding revert reasons from the output data.

Fix:

• Added revertReasonDecoded(String) method to CallTracerResult.Builder for setting revertReason without hex fallback
• Updated CallTracerErrorHandler.handleRootError() and CallTracerErrorHandler.setOutputAndErrorStatus() to use
  JsonRpcErrorResponse.decodeRevertReason()
• Only sets revertReason field when the revert data is a valid Error(string) format (starts with 0x08c379a0), ensuring Geth compatibility

Files Changed:

• CallTracerResult.java - Added revertReasonDecoded() method
• CallTracerErrorHandler.java - Added revert reason decoding logic

Issue 2: Missing nested calls array when transaction reverts

Problem:
When a transaction reverted, Besu's callTracer was not capturing nested calls at all. The calls array was completely missing from the output, even
though Geth includes all nested calls up to the point of revert.

Root Cause:
CallTracerResultConverter.buildCallHierarchyFromFrames() had an early return that prevented frame processing for ALL unsuccessful transactions,
including reverts.

Fix:

• Modified the condition to only skip frame processing for exceptional halts (stack underflow, out of gas, etc.)
• Reverted transactions now process frames normally and populate the nested calls array
• This ensures proper call tree reconstruction even when transactions revert

Files Changed:

• CallTracerResultConverter.java - Updated condition in buildCallHierarchyFromFrames()

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[macfarla]

changelog?