feat(bindings/dotnet): add Exists and Check

[Fatorin]

Which issue does this PR close?

None.

Rationale for this change

The .NET binding has no way to test for a path without handling a NotFound exception, and no way to verify that an operator can reach its service. Operator::exists and Operator::check cover both in core, and the Python and Node.js bindings already expose them.

Exists keeps the NotFound handling on the Rust side, so callers get a bool instead of an exception for the common "is it there?" question. Check gives applications a startup probe that fails on wrong credentials or an unreachable endpoint instead of surfacing the problem on the first real operation.

What changes are included in this PR?

• Add Operator.Exists and Operator.ExistsAsync, backed by operator_exists and operator_exists_async. They return false when the backend reports NotFound and throw for any other error, matching Operator::exists in core. The new OpendalBoolResult/OpenDALBoolResult pair carries the value across the FFI boundary the same way the other result structs do.

• Add Operator.Check and Operator.CheckAsync, backed by operator_check and operator_check_async, which forward to Operator::check in core.

• Add behavior tests for both. The Exists tests sit with the stat tests, and the Check tests mirror core's test_check, which is registered with the list tests and runs when the service supports read, write, and list.

• Document Exists under "Check existence and metadata" and Check in a new "Verify the connection" section of the .NET guide.

Are there any user-facing changes?

Yes. Four public methods are added to Operator. Nothing existing changes, so no migration is needed.

Breaking changes

None.

AI Usage Statement

• Harness: Claude Code (desktop app)
• Model: Claude Opus 5 (claude-opus-5)
• Effort: xhigh
• Role: Compared the binding's public surface against core's Operator to find the missing operations, then wrote the FFI functions, the managed API, the tests, and this description under the author's direction. The author chose the scope and the commit layout, decided to keep a dedicated bool result struct rather than reusing OpendalResult with an out parameter, and reviewed every change. Unknown affecting review: the behavior tests ran against the memory and fs services only, so no network service exercised the new calls.