Enhancement: Align Error API with Rust CDK

[Andrei1998]

The Error module provides the user-facing API for working with errors resulting from performing inter-canister calls. Currently, it provides the following function to determine whether immediately retrying a call upon failure would make sense:

/// Returns whether retrying to send a message may result in success.
/// [...]
public func isRetryPossible(error : Error) : Bool

In contrast, the Rust CDK currently provides richer API with more precise documentation:

/// Checks if the error is a clean reject.
/// A clean reject means that there must be no state changes on the callee side.
fn is_clean_reject(&self) -> bool;

/// Determines if the failed call can be retried immediately within the update method
/// that's handling the error, as opposed to relying on a background timer or heartbeat.
///
/// A return value of `true` indicates that an immediate retry *might* succeed, i.e., not result in another error.
/// However, the caller is responsible for ensuring that retries are safe in their specific context.
/// For idempotent methods, immediate retries are generally safe. For non-idempotent ones,
/// checking [`is_clean_reject`](CallErrorExt::is_clean_reject) before retrying is recommended.
fn is_immediately_retryable(&self) -> bool;

Proposals

1. Rename isRetryPossible to isImmediatelyRetryable and expand the docstring.

• Pro: name more representative of intended meaning.
• Con: breaking change.
• Alternative: expand the docstring, but don't update the name.

2. Introduce an isCleanReject(error : Error) : Bool function mirroring the semantics in the Rust CDK.

This would align Motoko with the Rust CDK, improve consistency across SDKs, and clarify the intended semantics.