feat(core): add conflict error kind

[Xuanwo]

Which issue does this PR close?

Implements RFC #8145.

Rationale for this change

ConditionNotMatch currently combines failed OpenDAL conditions with provider-side resource-state conflicts. Those outcomes require different recovery, and retryability depends on the operation that received the error rather than the error kind alone.

What changes are included in this PR?

• Add ErrorKind::Conflict and narrow the public ConditionNotMatch and retry contracts.
• Classify S3, GCS, and Azure Blob errors by native error code and operation context before falling back to HTTP status.
• Keep S3 PutObject conditional conflicts temporary while leaving multipart completion conflicts permanent because recovery requires a new upload session.
• Translate Azure no-replace errors according to if_not_exists and internal state-transition context.
• Expose Conflict from the C, Go, Java, Python, .NET, Haskell, and Zig bindings without renumbering existing error values.
• Add focused parser and binding regression coverage.

Are there any user-facing changes?

Yes. Provider-side operation conflicts that were previously reported as ConditionNotMatch now use Conflict. Existing OpenDAL conditions still use ConditionNotMatch, and unconditional create-style collisions continue to use AlreadyExists where applicable. Retry status remains independent from the error kind.

AI Usage Statement

AI materially assisted with implementation and test drafting. I reviewed the changes and verified them against the accepted RFC and current provider documentation. The provider mappings were not reproduced against live S3, GCS, or Azure Blob accounts. The Zig source was format-checked, but the local Zig build test was blocked by host macOS linker errors; the generated C API and Rust binding crates compile.