new feature: support mode argument in `op.open` in python binding correctly

### Feature Description

The Python binding implements `open` method on `Operator` instance, and it's generally expected that the behavior should be compatible with the builtin `open` function. Unfortunately, it's wrong when handling the `mode` argument.

The following arguments are valid for the mode argument:

ref: https://www.manpagez.com/man/3/fopen/

> r Open text file for reading. The stream is positioned at the
> beginning of the file.
> r+ Open for reading and writing. The stream is positioned at the
> beginning of the file.
> w Truncate to zero length or create text file for writing. The
> stream is positioned at the beginning of the file.
> w+ Open for reading and writing. The file is created if it does not
> exist, otherwise it is truncated. The stream is positioned at
> the beginning of the file.
> a Open for writing. The file is created if it does not exist. The
> stream is positioned at the end of the file. Subsequent writes
> to the file will always end up at the then current end of file,
> irrespective of any intervening fseek(3) or similar.
> a+ Open for reading and writing. The file is created if it does not
> exist. The stream is positioned at the end of the file. Subse-
> quent writes to the file will always end up at the then current
> end of file, irrespective of any intervening fseek(3) or similar.

Then in Python 3, all above modes represent TEXT mode, and all read/write methods accept `str` as arguments. An optional character `t` or `b` can be attached with the above modes, means `TEXT` and `BINARY`.

It seems that opendal treat them all as BINARY mode. It's the default behavior, and opendal will not reject invalid modes that it can't support.

### Problem and Solution

There are several actions can be taken for the purpose.

* Reject `a` and `+` in modes due to lack of support by the object store interface.
* Introduce `enum IoMode { Text, Binary }` to support `b` argument.
* Considering change the default behavior from `rb` to `rt`.

### Additional Context

_No response_

### Are you willing to contribute to the development of this feature?

- [X] Yes, I am willing to contribute to the development of this feature.

Start at the Python binding's `Operator.open` entry point and compare its mode handling with Python's builtin `open` and the listed `fopen` modes. Resolve which modes and text/binary behavior should be supported, then verify that valid modes are handled consistently and unsupported modes are rejected or otherwise specified.

Written by the indexing model from the issue text.